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Foreword 

This European Telecommunication Standard (ETS) has been produced by the Radio Equipment and 
Systems (RES) Technical Committee of the European Telecommunications Standards Institute (ETSI). 



This ETS is a multi-part standard and will consist of the following parts: 


Parti: 


"General network design". 


Part 2: 


"Air Interface (Al)". 


Part 3: 


"Inter-working", (DE/RES-06001-3). 


Part 4: 


"Gateways", (DE/RES-06001-4). 


Part 5: 


"Terminal equipment interface", (DE/RES-06001-5). 


Part 6: 


"Line connected stations", (DE/RES-06001-6). 


Part 7: 


"Security". 


Part 8: 


"Management services", (DE/RES-06001-8). 


Part 9: 


"Performance objectives", (DE/RES-06001-9). 


Part 10* 


"SuDDlementarv Services (SS) Staae 1". 


Part 11: 


"Supplementary Services (SS) Stage 2", (DE/RES-06001 -11). 


Part 12: 


"Supplementary Services (SS) Stage 3", (DE/RES-06001 -1 2). 


Part 13: 


"SDL Model of the Air Interface", (DE/RES-06001 -13). 


Part 14: 


"PICS Proforma", (DE/RES-06001 -14). 


Part 15: 


"Inter-working - extended Operations", (DE/RES-06001 -15). 


Part 16: 


"Gateways for Supplementary Services", DE/RES-06001 -16). 



Transposition dates 
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Date of withdrawal of any conflicting National Standard (dow): 
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1 Scope 

This ETS defines the Trans-European Trunked RAdio system (TETRA) supporting Voice plus Data (V+D). 
It specifies the air interface, the inter-working between TETRA systems and to other systems via 
gateways, the Terminal Equipment (TE) interface on the Mobile Station (MS), the connection of Line 
Stations (LSs) to the infrastructure, the security aspects in TETRA networks, the management services 
offered to the operator, the performance objectives, and the supplementary services that come in addition 
to the basic and tele-services. 

This part applies to the TETRA V+D Air Interface (Al) and contains the specifications of the physical layer, 
the DLL and the network layer according to the ISO model. 

First, it establishes the TETRA radio aspects (layer 1): 

it defines and specifies the modulation; 

it defines and specifies the radio transmission and reception; 

it defines and specifies the synchronisation; 

it defines and specifies the channel coding; 

it defines and specifies the channel multiplexing; 

it defines and specifies the control over the radio link. 

Secondly, it establishes the services, messages and protocols used for voice and circuit mode data 
transfer, starting with the upper layers: 

it defines and specifies the protocol used by the Circuit Mode Control Entity (CMCE) to 
communicate across the air interface in order to offer the services of the Call Control (CC), 
Supplementary Service (SS) and Short Data Service (SDS) sub-entities; 

it defines and specifies the services provided by the CC sub-entity; 

it defines and specifies the services provided by the SS sub-entity; 

it defines and specifies the services provided by the SDS sub-entity; 

it defines and specifies the services and protocol used for the management of the users' mobility 
inside and across TETRA networks, namely the ones of the Mobility Management (MM) entity and 
the MLE; 

it defines and specifies the services and protocol used in the DLL subdivided in two sub-entities, the 
Logical Link Control (LLC) and the Medium Access Control (MAC) entities. 

Thirdly, it establishes the services, messages and protocols used for packet data transfer: 

it defines and specifies the services and protocol used by the Connection Oriented Network Service 
(CONS); 

it defines and specifies the services and protocol used by the Specific ConnectionLess Network 
Service (SCLNS). 

The normative annexes mainly specify the parameter values used in the protocol. 

The informative annexes refer mainly to the description of more general layer 3 to layer 1 mechanisms. 
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2 Normative references 

This ETS incorporates by dated and undated reference, provisions from other publications. These 
normative references are cited at the appropriate places in the text and the publications are listed 
hereafter. For dated references, subsequent amendments to or revisions of any of these publications 
apply to this ETS only when incorporated in it by amendment or revision. For undated references the latest 
edition of the publication referred to applies. 

[I] CCITT Recommendation X.25 (1988): "Interface between data terminal 
equipment (DTE) and data circuit-terminating equipment (DCE) for terminals 
operating in the packet mode and connected to public data networks by 
dedicated circuit". 

[2] ISO 3309: "High-level data link control (HDLC) procedures - Frame structure". 

[3] ISO 7498: "Information processing systems - Open systems interconnect - Basic 

reference model". 

[4] ISO 8208: "X25 packet layer protocol for Data Terminal equipment". 

[5] ISO 8348: "Information processing systems - Data communications-Network 

service definition.". 

[6] ISO 8473: "Information processing systems - Protocol for providing the 

connectionless-mode network service". 

[7] ISO TR8509: "Information processing systems - ISO service conventions". 

[8] ISO 8648: "Information processing systems - Internal organisation of the 

network layer". 

[9] ISO 8878: "Use of X25 to provide the OSI connection mode network service". 

[10] ETS 300 113: "Radio Equipment and Systems (RES); Land mobile service; 

Technical characteristics and test conditions for radio equipment intended for 
the transmission of data (and speech) and having an antenna connector". 

[II] ETS 300 392-1 (1995): "Radio Equipment and Systems (RES); Trans-European 
Trunked Radio (TETRA) system; Voice plus Data; Part 1: General network 
design". 

[12] ETS 300 125: "Integrated Services Digital Network (ISDN); User-network 

interface data link layer specification; Application of CCITT Recommendations 
Q.920/I.440 and Q.921/1.441". 

3 Definitions, symbols and abbreviations 
3.1 Definitions 

For the purposes of this ETS, the following definitions apply: 

access code: A subdivision of mobiles for random access opportunities. 

acknowledged data transfer: A service provided by the layer below which gives an acknowledgement 
back over the air interface from the lower layer peer entity. This service is used by the layer 3 entities to 
get a secure transmission including re-transmissions. 

advanced link: An advanced link is a bi-directional connection oriented path between one MS and a BS 
with provision of acknowledged and unacknowledged services, windowing, segmentation, extended error 
protection and choice among several throughputs. It requires a set-up phase. 
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announced cell re-selection: Cell re-selection where MS-MLE informs the SwMI both in the old cell 
(leaving cell) and in the new cell (arriving cell) that cell change is performed. There can be three types of 
announced cell re-selection: 

type 1 : The MS-MLE knows the new cell and the traffic channel allocations on the cell before 
deciding to leave its serving cell; 

type 2: The MS-MLE knows the new cell before changing to it, but does not know the channel 
allocation on the new cell in advance; 

type 3: The MS-MLE need not to know the new cell before changing to it. The old cell is only 
informed by the MS-MLE that it wants to change cell. 

TETRA V+D may support all three types of announced cell re-selection. 

assigned channel: A channel that has been allocated by the infrastructure to certain MSs using channel 
allocation command(s) addressed to those MSs. An assigned channel may be allocated for secondary 
control purposes or for a circuit mode call. 

Associated Control CHannel (ACCH): The dedicated signalling channel associated with a channel that 
has been assigned for circuit mode traffic. It comprises the Fast Associated Control CHannel (FACCH) 
which uses frames 1 to 17 (if they are not used by traffic) plus the Slow Associated Control CHannel 
(SACCH) which is always available in frame 1 8. 

attached: A MS is said to be attached to a cell when the MS is camped and registered on the cell. The 
MS may be in idle mode (i.e. not actively processing a transaction) or in active mode (i.e. actively 
processing a transaction in reception and/or in transmission). It is the MM which decides when a MS is 
said to be attached. 

background measurement: Measurements performed by the lower layers while maintaining current 
service toward the service users, i.e. MS-MLE. 

basic link: A bi-directional connectionless path between one or several MS and a BS, with a provision of 
both unacknowledged and acknowledged services on a single message basis. 

Bit Error Ratio (BER): The limit ratio of the bits wrongly received to all bits received in a given logical 
channel. 

broadcast: A unidirectional point to multi-point mode of transmission. 

call acceptance type: This is used for group calls signalling to differentiate between group calls in which 
the user application is offered the call and those group calls where the MS is placed immediately into the 
call without being offered to the user application. 

call related service: A service is call related if it is requested from call set-up initiation until call 
disconnection and also related to the same call. It can also be valid a certain short time after 
disconnection but before next call set-up is initiated. 

call transaction: All of the functions associated with a complete unidirectional transmission of information 
during a call. A call can be made up of one or more call transactions. In a semi-duplex call these call 
transactions are sequential. 

call unrelated service: A service is call unrelated if it is either requested outside a call or inside a call but 
not referring to that actual call. 

called user application: The user application which receives an incoming call, 
calling user application: The user application which initiates an outgoing call. 
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camped: A MS is said to be camped on a cell when the MS is synchronised on the cell BS and has 
decoded the Broadcast Network Channel (BNCH) of the cell. The synchronisation procedure is performed 
by the MAC and the interpretation of the network information from the BNCH is performed by a procedure 
in the MLE. It is the MLE which decides when a MS is said to be camped on a cell. 

cell re-selection: The act of changing the serving cell from an old cell to a new cell. The cell re-selection 
is performed by procedures located in the MLE and in the MAC. When the re-selection is made and 
possible registration is performed, the MS is said to be attached to the cell. 

cell-id: Characterised as the channel number of the main carrier on the cell. 

common control channels: The control channels transmitted by the infrastructure to control the MS 
population. They comprise the Main Control Channel (MCCH) and common Secondary Control Channels 
(SCCH). 

confirmed service: A service provided by the layer below which ensures that a message is responded to 
by the peer entity before new messages are allowed. The service may be used for synchronisation of peer 
entities or for provision of sequential behaviour. 

current serving BS: The BS on one of whose channels the MS is currently operating. 

direct set-up signalling: A signalling procedure where immediate communication can take place 
between the calling and the called users without the alerting process and without an explicit response from 
the called user that he has answered. 

duplex frequency spacing: The fixed frequency spacing between up and downlink frequencies 
directions as defined in clause 6. 

foreground measurement: Measurements performed by the lower layers while employing the whole 
capacity, e.g. no concurrent service is maintained. 

half duplex operation: In half duplex operation, each MS or LS needs to ask for permission to transmit 
for each transaction. 

initial cell selection: The act of choosing a first serving cell to register in. The initial cell selection is 
performed by procedures located in the MLE and in the MAC. When the cell selection is made and 
possible registration is performed, the MS is said to be attached to the cell. 

interrupted measurement: Measurements performed by the lower layers interrupting current services. 

LLC frame: A LLC frame is the generic name given to one LLC data message, regardless the type of link 
(basic or advanced) used. An LLC frame comprises of a TL-SDU and LLC headers and a frame check 
sequence if applied. An LLC frame may be segmented for transmission. 

logical channel: A generic term for any distinct data path. Logical channels are considered to operate 
between logical endpoints. 

MAC block: The unit of information transferred between the upper MAC and lower MAC for a particular 
logical channel (e.g. SCH/F, SCH/HD or SCH/HU). The lower MAC performs channel coding for insertion 
into the appropriate physical slot, half slot or subslot. 

Main Control Channel (MCCH): The principal common control channel transmitted by the infrastructure 
to control the MSs in a cell. The frequency of the main carrier for the cell is broadcast by the infrastructure, 
and the MCCH is located on timeslot 1 of the main carrier. 

Message Erasure Rate (MER): The limit ratio of the messages detected as wrong by the receiver to all 
messages received in a given logical channel. 

message trunking: A traffic channel is permanently allocated for the complete duration of the call, which 
may include several separate call transactions (several pressel activation's by separate terminals). The 
channel is only de-allocated if the call is (explicitly) released or if a time-out expires. 
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Minimum Control Mode (MCM) (or minimum mode): A mode of operation in which the infrastructure 
allocates all four timeslots of the main carrier for traffic or assigned control purposes. In this mode, only 
frame 18 can be used for common control without disturbing the established services. 

monitoring: The act of measuring the power of neighbour cells and calculate the path loss parameter C2 
based upon information on neighbour cells broadcasted by the serving cell. 

MS timing offset: The delay of the received signal relative to the expected signal from an MS at zero 
distance under static channel conditions. 

Normal Control Mode (NCM) (or normal mode): A mode of operation in which the MCCH is present in 
timeslot 1 of all frames 1 to 18. 

on/off hook signalling: A signalling procedure which includes an alerting process to the called user. The 
calling user waits for an explicit response from the called user that he has answered before the call can be 
set-up. 

piggy-backing: A method of sending a layer 3 message concatenated with a layer 2 acknowledgement in 
the same air interface transmission. 

Probability Of Undetected Erroneous Message (PUEM): The limit ratio of the erroneous messages 
detected as right by the receiver to all messages received in a given logical channel. 

protocol entity instance: An instance of a protocol entity refers to one independent process related to 
the protocol defined by that entity. There may be multiple protocol entity instances running simultaneously 
but independently from each other. 

quarter symbol number: The timing of quarter symbol duration 125/9 jjs within a timeslot. 

quasi transmission trunking: A traffic channel is allocated for each call transaction (while the pressel is 
activated) and in addition the channel de-allocation is delayed for a short period at the end of the 
transaction (after the pressel release). During this "channel hang-time" the channel allocation may be re- 
used for a new call transaction that is part of the same call. A delayed channel de-allocation procedure 
applies at the end of each transaction. 

random access attempt: The period from the initiation of the random access procedure until the MS 
receives a response from the BS or abandons the procedure (e.g. after sending the maximum permitted 
number of retries). 

ranking: A procedural method of listing cells in descending order from the most suitable for 
communication to the least suitable for communication. As inputs to the ranking procedure are: 

outputs from the monitor process (e.g. C2 parameters); 

outputs from the scanning process (e.g. C1 parameters); 

network parameters received in the MLE broadcast. 

received SDU number: The received SDU number N(R) is the number of the received data TL-SDU. 

received segment sequence number: The number of the currently received segment. 

scanning: The act of measuring the power of neighbour cells and calculate the path loss parameter C1 
based upon the information on the neighbour cells broadcasted by the neighbour cells themselves. 

SDU number: A number on the advanced link to keep TL-SDUs in order. 

Search Area (SA): An area comprising all Location Areas (Las) where a MS may search for service. The 
search area is considered to be defined at subscription. Some means of changing the search area during 
operation could be considered. However, the method of loading SA into the MS and change it accordingly 
is considered to be outside the scope of this ETS. 



Page 34 

ETS 300 392-2: March 1996 

Secondary Control Channel (SCCH): A control channel other than the MCCH. There are two types of 
SCCH: 

a common SCCH, which has the same functionality as the MCCH but is used only by a subset of 
the MS population; 

an assigned SCCH, which may be allocated to certain MSs after an initial random access or paging 
message. 

segment: A LLC segment is the advanced link unit of transmission and re-transmission. A segment is the 
numbered piece of a TL-SDU fitting into one MAC layer PDU (MAC block). 

sent SDU number (N(S)): The sent SDU number N(S) is the number of the current TL-SDU. This number 
is incremented in a modulo manner with each transmitted TL-SDU. 

sent segment sequence number (S(S)): The sent segment sequence number S(S) is the number of the 
currently sent segment. 

serving cell: The cell that is currently proving service to the MS. 

surveillance: The process of monitoring the quality of the radio link to the serving cell. 

subscriber class: A subscriber class has no other defined usage than offering a population subdivision. 
The operator defines the values and meaning of each class. 

Time Division Multiple Access (TDMA) frame number: The timing of TDMA frames within a multiframe. 
timebase: A device which determines the timing state of signals transmitted by a BS or MS. 
timeslot number: The timing of timeslots within a TDMA frame. 

TLC-SAP: The management Service Access Point (SAP) is a way of modelling layer-to-layer 
communication for management and control purpose. 

transmission trunking: A traffic channel is individually allocated for each call transaction (for each 
activation of the pressel). The channel is immediately de-allocated at the end of the call transaction 
(subject to unavoidable protocol delays). 

unacknowledged data transfer: A service provided by the layer below which does not give any 
acknowledgement back to over the air interface from the lower layer peer entity. 

unannounced cell re-selection: Cell re-selection where the MS-MLE does not inform the old cell 
(leaving cell) that it intends to change to a new cell. Only the new cell (arriving cell) is informed about the 
MS-MLE. 

unconfirmed service: A service provided by the layer below which does not ensure response from peer 
entities before allowing new messages. This implies that messages to be transported may arrive in a 
different order at the peer entity since the sequence cannot be ensured. 

undeclared cell re-selection: Cell re-selection where the MS-MLE does not inform the old cell (leaving 
cell) nor the new cell (arriving cell) that cell change is performed. 

useful part of a burst: The scrambled bits of a burst. 

3.2 Symbols and Abbreviations 

For the purposes of this ETS, the following abbreviations apply: 

AACH Access Assignment CHannel 

ACCH Associated Control CHannel 

BBK Broadcast BlocK 

BCC Base station Colour Code 
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BCCH 


Broadcast Control CHannel 


BER 


Bit Error Rate 


BKN 


BlocK Number 


BLCH 


Base station Linearisation CHannel 


BN 


Bit Number 


BNCH 


Broadcast Network CHannel 


BS 


Base Station 


BSCH 


Broadcast Synchronisation CHannel 


CB 


Control uplink Burst 


CC 


Call Control 


CCH 


Control CHannel 


CLCH 


Common Linearisation CHannel 


CLNP 


ConnectionLess Network Protocol 


CMCE 


Circuit Mode Control Entity 


CONP 


Connection Oriented Network Protocol 


CP 


Control Physical channel 


CRC 


Cyclic Redundancy Check 


D-CT 


Downlink Continuous Transmission 


D-CTT 


Downlink Carrier Timesharing Transmission 


DL 


DownLink 


DLL 


Data Link Layer 


D-MCCTT 


Downlink Main Control Channel Timesharing Transmission 


DQPSK 


Differential Quaternary Phase Shift Keying 


ECCH 


Extended Control CHannel 


FCS 


Frame Check Sequence 


FN 


Frame Number 


ISO 


International Organisation for Standardisation 


LB 


Linearisation Burst 


LCH 


Linearisation CHannel 


LLC 


Logical Link Control 


LLME 


Lower Layer Management Entity 


LO 


Line station Originating 


LS 


Line Station 


LT 


Line station Terminating 


MAC 


Medium Access Control 


MCCH 


Main Control CHannel 


MCM 


Minimum Control Mode 


MER 


Message Erasure Rate. 


MLE 


Mobile Link Entity 


MM 


Mobility Management 


MN 


Multiframe Number 


MO 


Mobile station Originating 


mod 


modulo (base for counting) 


MPN 


Monitoring Pattern Number 


MS 


Mobile Station 


MST 


Multiple Slot Transmission 


MT 


Mobile station Terminating 


N(R) 


Received SDU (TL-SDU) number 


N(S) 


Sent SDU (TL-SDU) number 


NCM 


Normal Control Mode 


NDB 


Normal Downlink Burst 


NS 


Network Service 


NSDU 


Network Service Data Unit 


NUB 


Normal Uplink Burst 


PACQ 


Probability of synchronisation burst acquisition 


PC 


Protocol Control 


PDO 


Packet Data Optimised 


PDU 


Protocol Data Unit 


PL 


Physical Layer 


PUEM 


Probability of Undetected Erroneous Message 


QoS 


Quality of Service 


S(R) 


Received segment Sequence number 


S(S) 


Sent segment Sequence number 
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SAP 


Service Access Point 


SB 


Synchronisation downlink Burst 


SCCH 


Secondary Control CHannel 


SCH 


Signalling CHannel 


SCLNP 


Specific Connection Less Network Protocol 


SCLNS 


Specific ConnectionLess Network Service 


SDS 


Short Data Service 


SDU 


Service Data Unit 


SN 


Symbol Number 


SS 


Supplementary Service 


SSN 


SubSlot Number 


STCH 


Stealing CHannel 


SwMI 


Switching and Management Infrastructure 


TCH 


Traffic CHannel 


TDMA 


Time Division Multiple Access 


TLA 


A layer 2 SAP (TLA-SAP) 


TLB 


A layer 2 SAP (TLB-SAP) 


TLC 


A layer 2 SAP (TLC-SAP) 


TL-primitive 


TETRA LLC sub-layer primitive of service 


TL-SDU 


SDU from the service user (i.e. MLE) 


TM-primitive 


TETRA MAC sub-layer primitive of service 


TM-SDU 


SDU from the layer above MAC (i.e. LLC) 


TMV-primitive 


TETRA MAC sub-layer virtual primitive of service 


TN 


Timeslot Number 


TP 


Traffic Physical channel 


TP-primitive 


TETRA Physical layer primitive of service 


UL 


UpLink 


UP 


Unallocated Physical channel 



4 Radio aspects 



4.1 Introduction 

This clause is an introduction to the radio aspects of the TETRA V+D standard. It consists of a general 
description of the organisation of the radio-related functions with reference to the clauses where each part 
is specified in details. Furthermore, it introduces the reference configuration that will be used throughout 
this ETS. 

4.2 Set of logical channels 

The radio subsystem provides a certain number of logical channels as defined in clause 9. The logical 
channels represent the interface between the protocol and the radio. 

4.3 Reference configuration 

For the purpose of elaborating the specification of the radio-related functions, a reference configuration of 
the transmission chain is used as shown in figure 1 . 

NOTE: Only the transmission part is specified, the receiver being specified via overall 
performance requirements. 

With reference to this configuration, the radio clauses address the following functional units: 

clause 5: differential encoding and modulation; 

clause 6: characteristics of transmitter and receiver; 

clause 8: coding, reordering and interleaving, and scrambling; 

clause 9: burst building and logical channel multiplexing. 

This reference configuration also defines a number of points of vocabulary in relation to the names of bits 
at different levels in the configuration. 
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0) 



ENCODER 



REORDERER 



INTERLEAVER 



fil 



SCRAMBLER 



(1) information bits (transmit) 

(2) encoded bits 

(3) interleaved bits 

(4) scrambled bits 

(5) multiplexed bits 

(6) modulation bits 

(7) modulation symbols 



LCH. 
MULTIPLEXER 



(5) 



BURST 
BUILDER 



(6) 



DIFFERENTIAL 
ENCODER 



(7) 



MODULATOR 



TRANSMITTER 



T 



Figure 1 : Reference configuration 

4.4 Error control schemes 

The different error control schemes are described in detail in clause 8. 

4.5 Multiple access and time slot structure 

The access scheme is TDMA with 4 physical channels per carrier. The carrier separation is 25 kHz. 

The basic radio resource is a timeslot lasting 14,167 ms (85/6 ms) transmitting information at a 
modulation rate of 36 kbit/s. This means that the time slot duration, including guard and ramping times, is 
510 bit (255 symbol) duration's. 



The following subclauses briefly introduces the structures of hyperframe, multiframe, frame, timeslot, and 
burst, as well as the mapping of the logical channels onto the physical channels. The appropriate 
specifications are found in clause 9. 
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4.5.1 Hyperframes, multiframes and frames 

A diagrammatic representation of the TDMA structure is shown in figure 2. 

1 hyperframe =60 multiframes ( = 61,2 s) 
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1 modulation bit duration = 250/9 /ys (~ 27,78 //s) 

Figure 2: V+D TDMA structure 

The hyperframe level defines the top level frame hierarchy. One hyperframe is subdivided into 60 
multiframes, and lasts 61 ,2 s. 

One multiframe is subdivided in 18 frames, and has a duration of 1,02 s. The eighteenth frame in a 
multiframe is a control frame. 

One frame is subdivided into 4 time slots, and has a duration of 170/3 ms = 56,67 ms. 

4.5.2 Time slots and bursts 

The time slot is a time interval of 85/6 ms * 14,167 ms, which corresponds to 255 symbol duration's. The 
up-link timeslots may be subdivided into 2 subslots. 

The physical contents of a time slot is carried by a burst. There are seven different types of bursts, as 
defined in clause 9. 

4.5.3 Mapping of logical channels onto physical channels 

Two types of physical channels are defined: 

the Traffic Physical channel (TP) carrying mainly traffic channels; and 

the Control Physical channel (CP) carrying exclusively the control channel. One CP channel is 
defined as the MCCH, the others are called Extended Control Channel (ECCH). The Radio 
Frequency (RF) carrier containing the MCCH is called the main carrier. 
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The mapping of the logical channels onto the physical channels, according to the mode of operation, is 
defined in clause 9. 

4.6 Coding, interleaving and scrambling 

The coding, interleaving and scrambling schemes associated with each logical channel shall be as 
specified in clause 8. 

4.7 Modulation 

The modulation scheme is 7i/4-shifted Differential Quaternary Phase Shift Keying (7t/4-DQPSK) with root- 
raised cosine modulation filter and a roll-off factor of 0,35. The modulation rate is 36 kbit/s. This scheme is 
specified in detail in clause 5. 

4.8 Transmission and reception 

The modulated stream is transmitted on a RF carrier. 

The specific RF channels, together with the requirements on the transmitter and the receiver 
characteristics are specified in clause 6. 

For Base Stations (BSs) and MSs, power classes are defined in clause 6. 

4.9 Other radio-related functions 

Transmission involves other functions. These functions, which may necessitate the handling of specific 
protocols between BS and MS, are the radio subsystem synchronisation, and the radio subsystem link 
control. 

The synchronisation incorporates: 

frequency and time acquisition by the receiver; 

adjustment of the timebase of the MSs. 

The requirements on synchronisation are specified in clause 7. 

The radio link control adaptive power control: 

this function adjusts the RF transmit power, in order to ensure that the required quality of 
transmission is achieved with the least possible radiated power. 

This function is managed by the MS during the initial access, and by the MS or BS during operational use. 
This function is provided for battery saving and reduction of interference levels. 

4.10 Performance 

Under typical urban fading conditions (i.e. multipath delays no greater than 5 jjs), the quality threshold for 
full-rate speech is reached at a C/I c (co-channel interference) value of 19 dB, and the dynamic reference 
sensitivity level is - 106 dBm for BSs and - 103 dBm for mobile equipment. Details of performance 
requirements in various channel conditions are given in clause 6. 
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4.1 1 TETRA modes of operation 

The TETRA modes of operation which are supported by this ETS and which impact on the radio 
descriptions are: 

transmission modes: 

Downlink Continuous Transmission (D-CT) mode; 

the D-CT mode is mandatory for MSs, i.e. such equipment shall be able to interwork 
with a TETRA BS that would be in the D-CT mode; 

Downlink Carrier Timesharing Transmission (D-CTT) mode; 

Downlink Main Control Channel Timesharing Transmission (D-MCCTT) mode; 

Multiple Slot Transmission (MST) mode; 

control modes: 

Normal Control Mode(NCM); 

the NC mode is mandatory for all TETRA equipment; 

Minimum Control Mode (MCM); 

the MC mode is mandatory only for the MSs. 

In the following subclauses, each of the above modes of operations are defined. 

4.1 1 .1 Transmission modes 

4.11.1.1 D-CT mode 

In the D-CT mode, the BS always uses the continuous downlink bursts. The transmission is continuous on 
the main carrier. On the other carriers discontinuous transmission is allowed but is transparent for the 
MSs. 

4.11.1.2 D-CTT mode 

In the D-CTT mode, a carrier frequency may be shared by several cells, each of its 4 physical channels 
being allocated independently to these cells. The BS uses the discontinuous downlink bursts. 

4.11.1.3 D-MCCTT mode 

In the D-MCCTT mode, the MCCH is shared by several cells, each of its frames being allocated 
independently to these cells. The BS uses the discontinuous downlink burst. 

4.11.1.4 U-MSTmode 

In the MST mode, two to four physical channels are used for the same communication. This is used for 
example to increase the data transmission rate or to mix voice and data. 

4.11.2 Control modes 
4.11.2.1 NCM 

The NCM provides the TETRA services with full performance. It requires the assignment of one MCCH. 
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4.11.2.2 MCmode 

The MC mode provides the TETRA services with reduced performance. In the MC mode, ail physical 
channels of each RF carrier should be devoted to traffic. 

5 Modulation 

5.1 Introduction 

The following subclauses apply to the baseband part of the transmitter. 

5.2 Modulation type 
The modulation used shall be. 

5.3 Modulation rate 

The modulation rate shall be 36 kbit/s. 

5.4 Modulation symbol definition 

B(m) denotes the modulation bit of a sequence to be transmitted, where m is the bit number. The 
sequence of modulation bits shall be mapped onto a sequence of modulation symbols S(k), where k is the 
corresponding symbol number. 

The modulation symbol S(k) shall result from a differential encoding. This means that S(k) shall be 
obtained by applying a phase transition D<j)(k) to the previous modulation symbol S(k-1), hence, in 
complex notation: 

S(k) = S(k-l)exp(jD^(k)) 

S(0)=1 0) 

The above expression for S(k) corresponds to the continuous transmission of modulation symbols carried 
by an arbitrary number of bursts. The symbol S(0) is the symbol before the first symbol of the first burst 
and shall be transmitted as a phase reference. 

The phase transition D<p(k) shall be related to the modulation bits as shown in table 1 and figure 3. 



Table 1 : Phase transitions 



B(2k-1) 


B(2k) 


om 


1 


1 


-3n/4 


0 


1 


+3rc/4 


0 


0 


+7C/4 


1 


0 


-Tl/4 



0 
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Figure 3: Modulation symbol constellation and possible transitions 

The complex modulation symbol S(k) shall take one of the eight values exp(j rm/4), where n = 2, 4, 6, 8 for 
even k and n = 1 , 3, 5 t 7 for odd fr. The constellation of the modulation symbols and the possible 
transitions between them are as shown in figure 3. 

5.5 Modulated signal definition 

The modulated signal, at carrier frequency f c . shall be given by: 

M(t) = Re{s(t)ocp(j(2^f c t + * 0 ))} (2) 
where: 

0o is an arbitrary phase; 

$(t) is the complex envelope of the modulated signal defined as: 

s(t)= is^t-to 

k=0 (3) 

where: 

K*is the maximum number of symbols; 
7 is the symbol duration; 

ti< = kT\s the symbol time corresponding to modulation symbol S(k)\ 

g(t) is the ideal symbol waveform, obtained by the inverse Fourier transform of a square root 

raised cosine spectrum G(f), defined as follows: 

G(f)=1 for |f|<(1-a)/2T 



G(f ) = ^0.5(l -sin(/r(2|f|T -l)/2a)) for (1 - a)/2T < |f | < (1 + a)/2T 

G(f) = 0 for |f|^(1+a)/2T (4) 

where a is the roll-off factor, which determines the width of the transmission band at a given symbol rate. 
The value of a shall be 0,35. For practical implementation, a time limited windowed version of g(t), 
designed under the constraints given by the specified modulation accuracy and adjacent channel 
attenuation may be applied. 

5.6 Modulation filter definition 

The ideal modulation filter shall be a linear phase filter which is defined by the magnitude of its frequency 
response jH(f)l = G(f). 
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5.7 Modulation block diagram 



A block diagram of the modulation process is shown on figure 4. This diagram is for explanatory purposes 
and does not prescribe a specific implementation. The modulation filter excited by the complex Dirac 
impulse function SftySft-tiJ ideally has an impulse response g(t). 
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Figure 4: Block diagram of the modulation process 



6 Radio transmission and reception 
6.1 Introduction 



This clause defines the requirements for the MS and the BS transceiver of the TETRA V+D system. This 
clause is applicable to TETRA systems operating at radio frequencies of 380 MHz to 520 MHz. 

NOTE: The values specified in this clause are based on calculations, simulations, or existing 
standards. It is, therefore, essential that these values are confirmed during the 
validation phase. The values for the number of RF carriers, the guard band and the 
duplex spacing should be specified when detailed frequency allocations and band 
plans for TETRA are known. 



6.2 Frequency bands and channel arrangement 

When used in dedicated TETRA frequency bands, TETRA MSs shall transmit in the TETRA uplink 
frequency band, and TETRA BSs shall transmit in the TETRA downlink frequency band. The uplink and 
downlink frequency bands are of equal width. Their edges shall be as follows: 

Fup, min - Fup, max (MHz): mobile transmit, base receive; 

Fdw t min ~ Fdw, max (MHz): base transmit, mobile receive. 

The TETRA RF carrier separation shall be 25 kHz. The uplink and downlink bands are divided into /VRF 
carriers. In order to ensure compliance with the radio regulations outside the band, a guard band of G kHz 
is needed at each side of both uplink and downlink bands. 

The centre frequencies of uplink RF carriers, F uPiC shall be given by 

F m c = Fup,min + 0,001 G + 0,025 (c - 0,5) (MHz), for c= 1 N, (5) 

and the corresponding centre frequency of downlink RF carriers, F dWt & shall be given by: 

Fdw.c = Fup,c + D for c = 1 A/. (6) 

When a TETRA system is operated in frequency bands used for analogue Private Mobile Radio (PMR), 
the uplink and downlink transmit and receive centre frequencies and the duplex spacing (D) will be 
allocated by the National Regulatory Administration (NRA). 

In all frequency bands, the TETRA stations shall use a fixed duplex spacing D. 
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6.3 



Reference test planes 



For the purpose of testing, all TETRA stations shall have at least one antenna connector. Measurements 
shall be carried out at the appropriate antenna connector of the equipment as specified by the 
manufacturer (1T, 1R or 2 in figure 5). If the equipment is provided with a built-in duplex filter or a 
separate associated filter, the requirements of this ETS shall be met when the measurements are carried 
out using the antenna connector of this filter. In case of equipment comprising several transmitters, only 
one transmitter shall be transmitting during all measurements, except for measuring intermodulation 
attenuation. 




Duplex 
filter 
(optional) 



to/from antenna or 
base station or base site 
combiner network 



1 T = antenna connector of Tx 

1 R = antenna connector of Rx 

2 = antenna connector of transceiver 

with duplexer (optional) 



Figure 5: Reference interconnection of transmitters and receivers at BS 
6.4 Transmitter characteristics 
6.4.1 Output power 

In the following subclauses, power is defined as the average power, measured through the square root 
raised cosine filter defined in clause 5 over the scrambled bits of one transmitted burst as defined in 
clause 9. 



The power at which MSs or BSs may operate are specified in the following subclauses. 
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6.4.1.1 BS 

The BS transmitter nominal power shall be as defined in table 2 according to its power class. 



Table 2: Nominal power of BS transmitters 



Power class 


Nominal power per carrier 


1 (40W) 


46 dBm 


2 (25W) 


44dBm 


3(15W) 


42 dBm 


4(10W) 


40 dBm 


5 (6.3W) 


38 dBm 


6(4W) 


36 dBm 


7 (2.5W) 


34 dBm 


8 (1 ,6W) 


32 dBm 


9(1W) 


30 dBm 


10(0,6W) 


28 dBm 



6.4.1.2 MS 

The MS nominal power shall be as defined in table 3 according to its power class. 



Table 3: Nominal power of MS transmitters 



Power class 


Nominal power 


1 (30W) 


45 dBm 


2(10W) 


40 dBm 


3(3W) 


35 dBm 


4(1W) 


30 dBm 



The different power levels needed for adaptive power control (see clause 10) shall have the values as 
defined in table 4, starting from the minimum power control level of 15 dBm (step level 7) up to the 
nominal power level corresponding to the class of the particular MS as stated in table 3. 



Table 4: MS power control levels 



Step level 


Power 


1 


45 dBm 


2 


40 dBm 


3 


35 dBm 


4 


30 dBm 


5 


25 dBm 


6 


20 dBm 


7 


15 dBm 



6.4.2 Unwanted conducted emissions 
6.4.2.1 Definitions 

Unwanted emissions are defined as conducted emissions at frequencies or time intervals outside the 
allocated channel. The specified limits shall be met under realistic conditions, for instance under varying 
antenna mismatch. Unless otherwise stated, unwanted emissions are specified for an equipment in the 
active transmit (act Tx) state, i.e. whenever this equipment transmits bursts, or whenever it ramps- 
up/linearizes or ramps-down. The non-active transmit (nonact Tx state is a state occurring during two 
timeslot durations (approximately 28 ms) before and after any active transmit state. 
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Figure 6: Schematic presentation of transmitter states 

An equipment is said to be in the non-transmit (non-Tx) state whenever it is not in the active or non-active 
transmit state (refer to figure 6). 



6.4.2.2 



Unwanted emissions close to the carrier 



The emissions in the following subclauses shall be measured through the square root raised cosine filter 
with a roll-off factor of 0,35, as defined in clause 5. 

Measurements shall be done at the nominal centre frequency and at the frequency offsets specified in 
table 5. When applicable, relative measurements (dBc) shall refer to the level measured at the nominal 
centre frequency. 



6.4.2.2.1 



Measurement over the useful part of the burst 



The levels given in table 5 shall not be exceeded at the listed frequency offsets from the nominal carrier 
frequency. 

Table 5: Maximum adjacent power levels 



Frequency offset 


Max. level 


25 kHz 


-60 dBc 


50 kHz 


-70 dBc 


75 kHz 


-70 dBc 



In any case, no requirement in excess of - 36 dBm shall apply. 

The specifications assume that the centre frequency is at the above listed frequency offsets from the 
nominal carrier frequency. The measured values shall be averaged over the scrambled bits of the burst 
(see clause 9). The scrambled bits shall have a pseudo-random distribution from burst to burst. 



6.4.2.2.2 



Measurement during the switching transients 



At the frequency offset from the nominal carrier frequency given below, peak power measurements shall 
be done, covering at least the ramp-up period and the ramp-down period (figure 7, periods fj and t 3 ) (see 
subclause 6.4.5 for definition of and k). 

The maximum hold level of - 50 dBc at a frequency offset of 25 kHz shall not be exceeded. This 
requirement does not apply to linearization channels. 



In any case no requirement in excess of - 36 dBm shall apply. 
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6.4.2.3 Unwanted emissions far from the carrier 

These unwanted emissions are emissions (discrete, wideband noise, modulated or un-modulated) 
occurring at offsets of equal to, or greater than, 100 kHz from the carrier frequency, measured in the 
frequency range 9 kHz to 4 GHz. 

a) Discrete spurious: 

the maximum allowed power for each spurious emission shall be less than - 36 dBm measured in 
100 kHz bandwidth. The lower part of the spectrum (near to 9 kHz) is subject to specific 
measurement methods. 

b) Wideband noise: 

the wideband noise levels, measured through the modulation filter defined in subclause 5.6 should 
not exceed the limits shown in table 6, for the power classes as stated, and at the listed offsets from the 
nominal carrier frequency. The requirements apply symmetrically to both sides of the transmitter band. 



Table 6: Wideband noise limits 



Frequency offset 


Maximum level 


MS class 4 (1W) 


MS class 3 (3W) 


MS class 2 (10 W) 
MS class 1 (30W) 
BS (all classes) 


100 kHz -250 kHz 


-75dBc 


-78 dBc 


- 80 dBc 


250 kHz - 500 kHz 


- 80 dBc 


- 83 dBc 


- 85 dBc 


500 kHz - fa 


- 80 dBc 


- 85 dBc 


- 90 dBc 


>fa 


-100 dBc 


-100 dBc 


-100 dBc 


NOTE: fa denotes the frequency offset corresponding to the near edge of the receive 
band. 



All levels in table 6 are expressed in dBc relevant to the actual transmitted power level, and in any case no 
limit tighter than - 70 dBm shall apply. 

6.4.2.4 Unwanted emissions during the CLCH and BLCH 

The following emissions shall be measured through a square root raised cosine filter with a roll-off factor 
of 0,35 as defined in clause 5. 

Peak transmitter power appearing at a frequency offset from the carrier of ± 25 kHz during the CLCH and 
BLCH shall not exceed - 30 dBc for a maximum period of 1 ms. At all other times during the CLCH and 
BLCH period emissions shall not exceed - 45 dBc. 

NOTE: 0 dBc refers to the transmit power during normal operation after the CLCH or BLCH. 

6.4.2.5 Unwanted emissions in the non-transmit state 
The specifications of subclause 6.5.4.2 apply. 

6.4.3 Unwanted radiated emissions 

Unwanted radiated emissions are emissions (whether modulated or un-modulated) radiated by the cabinet 
and structure of the equipment (MS or BS). This is also known as cabinet radiation. 

The limits given in subclause 6.4.2.3 shall apply. 

6.4.4 RF tolerance 

The RF tolerance for BSs and MSs is defined in clause 7. 
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6.4.5 



RF Output power time mask 



The transmit level versus time mask for TETRA station transmission is shown in figure 7. For the time 
mask the power level of 0 dBc refers to the output power level of the TETRA station under consideration. 

Tx level 




time 



Symbol time of SNO 



2 ,3 

symbol time of SNmax 



Figure 7: Transmit level versus time mask 
Table 7: Transmit level versus time mask symbol durations (re figure 7) 



Burst Type 


'r 


t2 


t* 


Control uplink 


16 


103 


15 


Linearisation uplink 


119 


0 


15 


Linearisation downlink 


107 


0 


0 


Normal uplink 


16 


231 (note) 


15 


Discontinuous downlink 


7 


246 (note) 


7 


Continuous downlink 


7 


266 (note) 


7 


NOTE: In the case of single slot transmission. In the case of continuous 
downlink transmission, the start and stop bursts as defined in 
subclause 9.4.5.1 are included in the time fpof the time mask. 



Whenever bursts are consecutively transmitted by the same TETRA station on the same frequency, the 
transmit level versus time mask applies at the beginning of the transmission of the first burst and at the 
end of the transmission of the last burst. 

The symbol numbers referred to as S/VOand SNmax are defined in clause 9. The timing of the transmitted 
bursts is specified in clause 7 The time periods //, and (3, whose durations are stated in table 7, are 
defined in the following way: 

the time f/ starts at the beginning of the ramp-up of the first burst, and expires just before the 
symbol time of SA/0; 



the time t 2 starts at the symbol time of SNO of the first burst and finishes at the symbol time of 
SNmax of the last burst; 
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the time f$ starts just after the symbol time of SNmax of the last burst and finishes at the end of the 
ramp-down. 

In this subclause, the specifications of subclauses 6.4.1 and 6.6.1 shall apply during the time fe. The 
output power shall be measured through the square root raised cosine filter with a roll off factor of 0,35 as 
defined in clause 5. 

6.4.5.1 BS (BS) 

The BS output power shall be at the nominal level, as specified in subclause 6.4.1.1. Power control shall 
not be applied to the downlink transmissions. 

In the non-active transmit state the specification L mm = - 40 dBc shall apply. 
The peak transmit power during BLCH shall not exceed + 6 dBc. 

6.4.5.2 MS (MS) 

The MS output power shall be able to be reduced by steps of 5 dB, down to a minimum level of 15 dBm. 
The power levels that can be achieved, according to the class of the MS, are detailed in subclause 
6.4.1.2. 

In the non-active transmit state the specification L min - - 70 dBc shall apply. In any case, no requirement 
in excess of - 40 dBm shall apply. 

6.4.6 Intermodulation attenuation 

6.4.6.1 Definition 

The intermodulation attenuation is the ratio of the power level of the wanted signal to the power level of an 
intermodulation component. It is a measure of the capability of the transmitter to inhibit the generation of 
signals in its non-linear elements caused by the presence of the useful carrier and an interfering signal 
reaching the transmitter via its antenna. 

6.4.6.2 BS 

In the case of BS equipment with only one transmitter, not collocated with other radio equipment operating 
in the TETRA frequency band, the intermodulation attenuation shall be at least 40 dB for any 
intermodulation component when measured in a 30 kHz bandwidth. The interfering signal shall be un- 
modulated and have a frequency offset of at least 100 kHz from the carrier frequency. The power level of 
the interfering signal shall be 30 dB below the power level of the modulated output signal from the 
transmitter under test. 

For all other cases, the intermodulation attenuation of the BS equipment shall be at least 70 dB for any 
intermodulation component when measured in a 30 kHz bandwidth. The interfering signal shall be un- 
modulated and have a frequency offset of at least 100 kHz from the carrier frequency. The power level of 
the interfering signal shall be 30 dB below the power level of the modulated output signal from the 
transmitter under test. If the intermodulation attenuation is achieved by additional, internal or external, 
isolating devices they shall be included in the measurements. 

In any case no requirement more stringent than -36 dBm shall apply to intermodulation components. 

All power levels stated in the cases above refer to the antenna connector of the BS described in 
subclause 6.3. 

6.4.6.3 MS 

In an MS, intermodulation may be caused when operating transmitters in the close vicinity of each other. 

For an MS transmitter operating at the nominal power defined by its class, the intermodulation attenuation 
shall be at least 60 dB for any intermodulation component when measured in 30 kHz bandwidth. The 
interfering signal shall be un-modulated and have a frequency offset of at least 100 kHz from the carrier 
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frequency. The power level of the interfering signal shall be 50 dB below the power level of the modulated 
output signal from the transmitter under test. 

6.4.7 Intra-BS intermodulation requirements 

In a BS, intermodulation may be caused by combining several transmitters and carriers to feed a single 
antenna. 

For all transmitters of a single TETRA BS operating at the maximum allowed power, the peak power of 
any intermodulation components, when measured in a 30 kHz bandwidth, shall not exceed - 60 dBc in the 
relevant downlink frequency band. In any case no requirement in excess of - 36 dBm shall apply. 

NOTE: The value of - 60 dBc refers to the carrier power measured at the antenna connector 
of the BS described in subclause 6.3. 

In the case where the performance is achieved by additional internal or external isolating devices (such as 
circulators) they shall be supplied at the time of conformance testing and shall be used for measurements. 

6.5 Receiver characteristics 

In this clause, the levels of the test signals are given in terms of power levels (dBm) at the antenna 
connector of the receiver. For the definition of power level refer to subclause 6.4.1 . 

Sources of test signals shall be connected in such a way that the impedance presented to the receiver 
input is a 50Q non-reactive impedance. 

This requirement shall be met irrespective of whether one or more signals using a combining network are 
applied to the receiver simultaneously. 

Static propagation conditions are assumed in all cases, for both wanted and unwanted signals. 
6.5.1 Blocking characteristics 

6.5.1.1 Definition 

Blocking is a measure of the capability of the receiver to receive a modulated wanted input signal in the 
presence of an unwanted un-modulated input signal on frequencies other than those of the spurious 
responses or the adjacent channels, without this unwanted input signal causing a degradation of the 
performance of the receiver beyond a specified limit. 

6.5.1 .2 Specification 

The blocking performance specification given in table 8 shall apply at all frequencies except those at 
which spurious responses occur (see subclause 6.5.2). 



Table 8: Blocking levels of the receiver 



Offset from nominal Rx f req. 


Level of interfering signal 


50 kHz to 100 kHz 


- 40 dBm 


100 kHz to 200 kHz 


- 35 dBm 


200 kHz to 500 kHz 


- 30 dBm 


> 500 kHz 


- 25 dBm 



The static reference sensitivity performance as specified in subclause 6.6.2.4 shall be met when the 
following signals are simultaneously input to the receiver: 

a wanted signal at the nominal receive frequency f 0i 3 dB above the static reference sensitivity level 
as specified in subclause 6.6.2.4; 

a continuous sine wave signal at a frequency offset from f 0 and level as defined in table 8. 
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6.5.2 Spurious response rejection 

6.5.2.1 Definition 

Spurious response rejection is a measure of the capability of a receiver to receive a wanted modulated 
signal without exceeding a given degradation due to the presence of an unwanted un-modulated signal at 
any other frequency at which a response is obtained, i.e. for which the blocking limit is not met. 

6.5.2.2 Specification 

The static reference sensitivity performance as specified in subclause 6.6.2.4 shall be met when the 
following signals are simultaneously applied to the receiver: 

a wanted signal at nominal receive frequency f 0 , 3 dB above the static reference sensitivity level as 
specified in subclause 6.6.2.4; 

a continuous sine wave signal at frequency fas defined below at a level of - 45 dBm. 

For any frequency within a limited frequency range, defined below at which the blocking specification of 
subclause 6.5.1.2 is not met. The number of such spurious responses shall not exceed 0,05 x (number of 
frequency channels in the limited frequency range). 

The limited frequency range is defined as the frequency of the local oscillator signal f to applied to the first 

mixer of the receiver plus or minus the sum of the intermediate frequencies (fa, fj n ) and a half of the 

switching range (si) of the receiver. 



Hence the frequency //of the limited frequency range is: 
j=t J /L j=1 fC 



(7) 



Where receiver switching range (st) is the maximum frequency range over which the receiver can be 
operated without reprogramming or realignment as declared by the manufacturer. 

6.5.3 Intermodulation response rejection 

6.5.3.1 Definition 

Intermodulation response rejection is a measure of the capability of the receiver to receive a wanted 
modulated signal without exceeding a given degradation due to the presence of two or more unwanted 
signals with a specific frequency relationship to the wanted signal frequency as defined in 
ETS 300 113 [10]. 

6.5.3.2 Specification 

The static reference sensitivity performance as specified in subclause 6.6.2.4 shall be met when the 
following signals are simultaneously input to the receiver: 

a wanted signal at the nominal receive frequency 3 dB above the static reference sensitivity 
level; 

a continuous sine wave signal at frequency U and with a level of - 47 dBm; 

a pseudo-random sequence TETRA modulating a signal at frequency with a level of 
- 47 dBm, such that f 0 = 2U - and | f r U I = 50 kHz. 
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6.5.4 Unwanted conducted emissions 

6.5.4.1 Definition 

Unwanted emissions from the equipment when in reception are defined as conducted emissions at any 
frequency, when the equipment is in the non-transmit state. 

6.5.4.2 Specification 

The peak power emitted by the equipment shall not exceed - 57 dBm at frequencies between 9 kHz and 
1 GHz, and - 47 dBm at frequencies from 1 GHz to 4 GHz, as measured in a bandwidth of 30 kHz. 

6.5.5 Unwanted radiated emissions 

Unwanted radiated emissions are emissions radiated by the cabinet and structure of the equipment (MS 
or BS) in the non-TX state. This is also known as cabinet radiation. 

The limits given in subclause 6.5.4.2 shall apply 

6.6 Transmitter/receiver performance 

Subclause 6.6.1 specifies the modulation accuracy requirement, by setting limits on the Root Mean 
Square (RMS) error between the actual transmitted signal waveform and the ideal signal waveform. 
Subclause 6.6.2 specifies the receiver performance, assuming that transmit errors do not occur. 
Subclause 6.6.3 specifies all the propagation models that are defined in this ETS. 

6.6.1 Modulation accuracy 

The specified requirement is vector error magnitude; this does not only take into account modulation 
filtering linear distortion (amplitude and phase) or modulator impairments (quadrature offset, phase and 
linear amplitude errors in the modulation symbol constellation) but is a measure of the whole transmitter 
quality. It also takes into account local oscillator phase noise, filter distortion, and non-linearity of 
amplifiers. Vector error magnitude shall be specified at symbol time (see subclause 6.6.1.2) and the 
vector error magnitude requirement shall be fulfilled by the TETRA equipment with maximum and with 
minimum power levels (as defined in subclause 6.4.1). 

6.6.1.1 Ideal case 

The modulation symbol s(t) transmitted by an ideal transmitter having a filter impulse response g(t) is 
defined in clause 5. 



Let Z(k) denote the output of an ideal receive filter with impulse response * The ideal transmit 

and receive filters in cascade form a raised cosine Nyquist filter, having a symbol waveform going through 
zero at symbol duration intervals, so there is no inter-symbol interference at any instant t = t kl where t k is 
the symbol time corresponding to the fr-th symbol (as defined in clause 5). 

In this case, the output of an ideal receive filter at any instant t kt stimulated by an ideal transmitter, will be 
equal to the /c-th modulation symbol S(k): 

Z(k) = s(t>.g(-t)| t=tk =S(k) (8) 
In this subclause, the numbering of the modulation symbols used is the one defined in clause 9. 
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6.6.1 .2 Vector error magnitude requirement at symbol time 



Let Z(k) be the output produced by observing the real transmitter through the ideal receive filter at symbol 
time Z(k) is modelled as: 

Z(k) = {c 0+ [S(k) + E(k)]}c,W(k) (9) 

where: 

E(k) is the vector error of modulation symbol S(k); ■ 

W(k) = expfikO) accounts for a frequency offset giving Q radians per symbol phase rotation due to 
transmitter frequency inaccuracy (see clause 7). The possible amplitude variations shall be 
integrated in the vector error; 

Co is a complex constant characterising the residual carrier; 

C 1 is a complex constant representing the output amplitude and initial phase of the transmitter. 

The magnitude of C 0 shall be less than 5 % of the magnitude of S(k). The task of the test receiver is then 
to: 

estimate the symbol time for processing the receive part; 

estimate the values of Co, C/ and &. The resulting estimates shall be denoted by Co\ C{ and &' 
respectively; 

perform a normalisation of the modulation symbol Z(k) accordingly. The modulation symbol that 
results from this normalisation shall be denoted by Z(k): 

Z'(k) = [z(k)exp(-jk0O/c l / ]-Q ) / (10) 

With the above notations, the Sum Square Vector Error (SSVE) is defined as: 



SNmat . 



2 



SSVE = I I Z'(k)-Sfk) (11) 
k=l 

where SNmax is the number of symbols in the burst. 

The RMS vector error is then computed as the square root of the sum-square vector error divided by the 
number of symbols in the burst: 



RMSVE => fSSVE^ Nma( , (12) 

The RMS vector error in any burst shall be less than 0,1 . 

The peak vector error magnitude jZ(k)-S(k)l shall be less than 0,3 for any symbol. 

6.6.2 Receiver performance 

This subclause specifies the minimum required receiver performance in terms of Bit Error Ratio (BER), 
Message Erasure Rate (MER) or Probability of Undetected Erroneous Message (PUEM) (whichever is 
appropriate), taking into account that transmitter errors do not occur, and that the transmitter shall be 
tested separately (see subclause 6.6.1). 

In this clause, the levels of the test signals are given in terms of power levels (dBm) at the antenna 
connector of the receiver. For the definition of power level refer to subclause 6.4.1 . 
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The receiver performance for the speech channel is not specified in this subclause. 

Three equipment classes are specified, distinguishing their intended operating environments and testing 
conditions. The classes have preferred operating conditions, as follows: 

Class B: equipment is optimised for use in built-up and urban areas. The specification guarantees 
good performance at the reference sensitivity and interference level in static and TU50 conditions, 
but not in extreme propagation conditions (hilly terrain); 

Class A: equipment is optimised for use in urban areas and in areas with hilly or mountainous 
terrain. It is resilient to extreme propagation conditions (hilly terrain) and is specified in static, TU50 
and HT200 conditions; 

Class E: equipment comprises an equaliser and is specified in static, TU50 and EQ200 conditions. 
It is not applicable to BS equipment. 

6.6.2.1 Nominal error rates 

This subclause describes the transmission requirements in terms of error ratios in nominal conditions i.e. 
without interference and with an input level of - 85 dBm. The relevant propagation conditions are given in 
subclause 6.6.3. 

Under the following propagation conditions, the BER of the non-protected bits, equivalent to the TCH/7 ,2 
shall have the limits given in table 9. 



Table 9: Nominal error rates 



Propagation model 


BER 


Equipment class 


STATIC 


0,01% 


A, B,E 


TU50 


0,40% 


A, B.E 


HT200 


3,00% 


A 


EQ200 


2,00% 


E 



This performance shall be maintained up to - 40 dBm input level for the static conditions, and multipath 
conditions. Furthermore, for static conditions, a BER of < 0,1 % shall be maintained up to - 20 dBm. 

6.6.2.2 Dynamic reference sensitivity performance 

The minimum required dynamic reference sensitivity performance is specified according to the logical 
channel, the propagation condition and the receiver class at the dynamic reference sensitivity level. The 
dynamic reference sensitivity level shall be: 

for MS: -103 dBm; 

forBS: -106 dBm. 

Tables 10 and 11 gives the minimum required dynamic reference sensitivity performance for TU50, 
HT200 or EQ200 propagation conditions. For BSCH, SCH/HD, SCH/HU, SCH/F and BNCH, a PUEM < 
0,001% shall be achieved at the dynamic reference sensitivity level. For AACH, a PUEM < 0,01% shall be 
achieved at the dynamic reference sensitivity level. 
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6.6.2.2.1 BS receiver performance 



Table 10: BS receiver performance (dynamic sensitivity) 





Class A 


Class B 


Logical channel 




propagation condition 


propagation 
condition 






TU50 


HT200 


TU50 


SCH/HU 


MER 


8% 


9.5% 


8% 


SCH/F 


MER 


11% 


11% 


8% 


TCH/7,2 


BER 


2,5% 


4% 


2,2% 


TCH/4,8 N=1 


BER 


4% 


4% 


2% 


TCH/4,8 N=4 


BER 


1,2% 


4% 


0.4% 


TCH/4,8 N=8 


BER 


0,4% 


4% 


0.06% 


TCH/2,4 N=1 


BER 


1.2% 


1 .3% 


0.35% 


TCH/2,4 N=4 


BER 


0.02% 


0,3% 


0,01% 


TCH/2,4 N=8 


BER 


0.01% 


0,15% 


0,01% 


STCH 


MER 


9% 


11% 


8% 


NOTE: N gives the interleaving depth in number of blocks (see clause 8). 



6.6.2.2.2 MS receiver performance 



Table 11: MS receiver performance (dynamic sensitivity) 





Continuous downlink mode 


Discontinuous downlink 
mode 


prop. 


propac 


lation condition 


propagation condition 


cond. 


TU50 


HT200 


EQ200 


TU50 


HT200 


TU50 


Logical channel 




Class A, E 


Class A 


Class E 


Class A 


Class A 


Class B 


AACH 


MER 


10% 


17% 


16% 


10% 


17% 


11% 


BSCH 


MER 


8% 


11% 


22% 


8% 


11% 


8% 


SCH/HD 


MER 


8% 


11% 


21% 


9% 


11% 


8% 


BNCH 


MER 


8% 


11% 


21% 


9% 


11% 


8% 


SCH/F 


MER 


8% 


11% 


22% 


11% 


11% 


8% 


TCH/7,2 


BER 


2,5% 


4% 


4,5% 


2,5% 


4% 


2.2% 


TCH/4,8 N=1 


BER 


2% 


4% 


6,4% 


4% 


4% 


2% 


TCH/4,8 N=4 


BER 


0,4% 


3.3% 


2,7% 


1.2% 


4% 


0,4% 


TCH/4,8 N=8 


BER 


0,06% 


3% 


1,5% 


0,4% 


4% 


0.06% 


TCH/2,4 N=1 


BER 


0.35% 


1,1% 


0,82% 


1,2% 


1,3% 


0,35% 


TCH/2,4 N=4 


BER 


0.01% 


0,4% 


0.017% 


0,02% 


0,4% 


0,01% 


TCH/2,4 N=8 


BER 


0.01% 


0,13% 


0,01% 


0,01% 


0.2% 


0,01% 


STCH 


MER 


8% 


11% 


21% 


9% 


11% 


8% 


NOTE: N gives the interleaving depth in number of blocks (see clause 8). 



6.6.2.3 Reference interference performance 

The minimum required reference interference performance (for co-channel, C/I c , or adjacent channel, 
C/la) is specified according to the logical channel, the propagation condition and the receiver class at the 
reference interference ratio. The reference interference ratio shall be, for BS and all types of MS: 



for co-channel interference: C// c = 1 9 dB; 

for adjacent channel interference: C/I a = - 45 dB. 

In case of co-channel interference these specifications apply for a wanted input signal level of - 85 dBm, 
and in case of adjacent channel interference for a wanted input signal level 3 dB above the dynamic 
reference sensitivity level. In any case the interference shall be a continuous TETRA random modulated 
signal subjected to an independent realisation of the same propagation condition as the wanted signal. 
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In table 12 and table 13 the performance for TU50, HT200 or EQ200 propagation conditions is given for 
the reference interference level. For BSCH, SCH/HD, SCH/HU, SCH/F, BNCH, a PUEM < 10" 5 shall be 
achieved at the reference interference level. For AACH a PUEM < 10* 4 shall be achieved at the reference 
interference level. 

6.6.2.3.1 BS receiver performance 



Table 12: BS receiver performance (interference) 





Class A 


Class B 


Logical channel 




propagation condition 


propagation 
condition 






TU50 


HT200 


TU50 


SCH/HU 


MER 


6,5% 


9,5% 


6,5% 


SCH/F 


MER 


6% 


7,5% 


6% 


TCH/7,2 


BER 


2% 


3,7% 


2% 


TCH/4,8 N=1 


BER 


4% 


4% 


2% 


TCH/4,8 N=4 


BER 


1,2% 


4% 


0,4% 


TCH/4,8 N=8 


BER 


0,4% 


4% 


0,06% 


TCH/2,4 N=1 


BER 


1,2% 


1,3% 


0,35% 


TCH/2,4 N=4 


BER 


0,02% 


0,3% 


0,01% 


TCH/2,4 N=8 


BER 


0,01% 


0,15% 


0,01% 


STCH 


MER 


7% 


9.2% 


7% 


NOTE: N gives the interleaving depth in number of blocks (see clause 8). 



6.6.2.3.2 MS receiver performance 



Table 13: MS receiver performance (interference) 





Continuous downlink mode 


Discontinuous downlink 
mode 


prop. 


propac 


lation condition 


propagation condition 


cond. 


TU50 


HT200 


EQ200 


TU50 


HT200 


TU50 


Logical channel 




Class A, E 


Class A 


Class E 


Class A 


Class A 


Class B 


AACH 


MER 


9% 


16% 


14% 


9% 


16% 


9% 


BSCH 


MER 


6% 


10% 


20% 


6% 


10% 


6% 


SCH/HD 


MER 


7% 


9,2% 


20% 


7% 


9,2% 


7% 


BNCH 


MER 


7% 


9,2% 


20% 


7% 


9.2% 


7% 


SCH/F 


MER 


6,5% 


7,5% 


20% 


6.5% 


7.5% 


6.5% 


TCH/7,2 


BER 


2% 


3.8% 


4,2% 


2% 


3,8% 


2% 


TCH/4,8 N=1 


BER 


2% 


4% 


6,2% 


4% 


4% 


2% 


TCH/4,8 N=4 


BER 


0,4% 


3,3% 


2,5% 


1,2% 


4% 


0,4% 


TCH/4,8 N=8 


BER 


0,06% 


3% 


1.2% 


0,4% 


4% 


0,06% 


TCH/2,4 N=1 


BER 


0.35% 


1.1% 


0,84% 


1,2% 


1,3% 


0,35% 


TCH/2,4 N=4 


BER 


0,01% 


0,4% 


0,01% 


0.02% 


0.4% 


0,01% 


TCH/2,4 N=8 


BER 


0,01% 


0,13% 


0,01% 


0.01% 


0,2% 


0.01% 


STCH 


MER 


7% 


9,2% 


20% 


7% < 


9.2% 


7% 


NOTE: N gives the interleaving depth in number of blocks (see clause 8). 



6.6.2.4 Static reference sensitivity performance 

The minimum required static reference sensitivity performance is specified according to the logical 
channel and the receiver class at the static reference sensitivity level. The static reference sensitivity level 
shall be: 



for MS: -112dBm; 



for BS: 



- 115 dBm. 
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Table 14 and table 15 give the minimum required reference sensitivity performance. For BSCH, SCH/HD, 
SCH/HU, SCH/F, BNCH, a PUEM < 0,001% shall be achieved at the static reference sensitivity level. For 
AACH a PUEM < 0,01% shall be achieved at the static reference sensitivity level. 

6.6.2.4.1 BS receiver performance 



Table 14: BS receiver performance (static sensitivity) 



Logical channel 




Class A 


Class B 


SCH/HU 


MER 


3% 


3% 


SCH/F 


MER 


10% 


10% 


TCH/7,2 


BER 


3% 


4% 


TCH/4,8 N=1 


BER 


3,3% 


0,3% 


TCH/4,8 N=4 


BER 


1% 


0,2% 


TCH/4,8 N=8 


BER 


0,4% 


0,2% 


TCH/2,4 N=1 


BER 


0,2% 


0,01% 


TCH/2,4 N=4 


BER 


0,01% 


0,01% 


TCH/2,4 N=8 


BER 


0,01% 


0,01% 


STCH 


MER 


8% 


5% 


NOTE: N gives the interleaving depth in number of blocks 
(see clause 8). 



6.6.2.4.2 MS receiver performance 



Table 15: MS receiver performance (static sensitivity) 



Logical channel 




Continuous 
downlink mode 


Discontinuous 
downlink mode 








Class A,E 


Class A 


Class B 


AACH 


MER 


28% 


28% 


38% 


BSCH 


MER 


3% 


3% 


3% 


SCH/HD 


MER 


2,5% 


8% 


5% 


BNCH 


MER 


2,5% 


8% 


5% 


SCH/F 


MER 


4,5% 


9% 


9% 


TCH/7,2 


BER 


3,5% 


3,5% 


4% 


TCH/4,8 N=1 


BER 


0,3% 


2% 


0,3% 


TCH/4,8 N=4 


BER 


0,2% 


0,8% 


0.2% 


TCH/4,8 N=8 


BER 


0.15% 


0,4% 


0.15% 


TCH/2,4 N=1 


BER 


0,01% 


0,01% 


0,01% 


TCH/2,4 N=4 


BER 


0,01% 


0,01% 


0,01% 


TCH/2,4 N=8 


BER 


0,01% 


0,01% 


0,01% 


STCH 


MER 


2,5% 


8% 


5% 


NOTE: N gives the interleaving depth in number of blocks (see clause 8). 



6.6.2.5 MS receiver performance for synchronisation burst acquisition 

This subclause specifies reference sensitivity performance of a MS receiver for the acquisition of the 
Synchronisation (sub) Burst (SB). The performance is defined in terms of the probability PACQ of 
detecting a single transmitted SB and correctly decoding its BSCH information for the condition where the 
MS is listening on the frequency while the SB is transmitted, and where the MS is already frequency 
synchronised but not synchronised in terms of time slots. 



Table 16: MS receiver performance for synchronisation burst acquisition 



Propagation condition/eq. class 


TU50/class B 


HT200/class A 


PACQ 


0,8 


0,8 


NOTE: This specification applies for continuous and discontinuous downlink mode. 
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6.6.3 



Propagation conditions 



The following subclauses contains all necessary information on the propagation models that are referred 
to in this ETS. 



Radio wave propagation in the mobile radio environment is described by dispersive multipath caused by 
reflection, diffraction and scattering. Different paths may exist between a BS and a MS due to large distant 
reflectors and/or scatterers and due to scattering in the vicinity of the mobile, giving rise to a number of 
partial waves arriving with different amplitudes and delays. Since the mobile will be moving, a Doppler shift 
is associated with each partial wave, depending on the mobile's velocity and the angle of incidence. The 
delayed and Doppler shifted partial waves interfere at the receiver causing frequency and time selective 
fading on the transmitted signal. 

When system bandwidth and propagation path lengths are sufficiently small (which is the case for 
TETRA), the resulting frequency and time selective fading process may be simulated by a simplified 
propagation model. Such a model exhibits only a few discrete paths which are independently fading. For 
practical channel simulation, stationary Gaussian processes with a power density spectrum equal to the 
classical Doppler spectrum are commonly assumed. 

Based on extensive investigations (Digital Land Mobile Radiocommunications, M. Failli (Ed.), Final Report 
14.3.1984-13.9.1988, published by European Commission, Directorate of General Telecommunication, 
Information Industries and Innovation. Luxembourg. ISBN 92-825-9946-9. (1989)) some tapped delay line 
models which are typical for urban, rural, or hilly area propagation conditions or for quasi synchronous 
operation were derived. These models are defined in the following terms (see also table 17): 

number of discrete taps; 
relative delay of each tap; 

average relative power of the complex tap-gain process of each tap; 

type of the complex tap-gain process of each tap. 
All stochastic tap-gain processes are mutually statistically independent. 
6.6.3.2 Tap-gain process types 

This subclause defines the statistical properties of the stationary complex tap-gain processes, to be 
applied for the propagation models, in terms of a Probability Density Function (PDF) and a Power Density 
Spectrum (PDS) which models the Doppler spectrum. The complex tap-gain processes, denoted by a(t) 
and defined hereunder, are normalised to unity power. 

CLASS is the tap-gain process having a PDS equal to the classical Doppler spectrum. The real and 
imaginary parts of a(t) exhibit an identical Gaussian PDF, an identical PDS and are mutually statistically 
independent. Hence \a(t)\ is Rayleigh distributed. The PDS of aft) is defined by: 



6.6.3.1 



Propagation conditions - introduction 



S(f) = S 




1 



for -f<j<f<fd and 



CLASS 



s(f) = o 



elsewhere 



(13) 



where the parameter f d represents the maximum Doppler shift (in Hz), defined as = v/k with the vehicle 
speed v(in m/s) and the wavelength A (in m). 
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STATIC(fs) is a tap-gain process with a constant magnitude ja(t)l=1. The PDS of a(t) is defined by: 

S(f) = S STATIC (f.f s ) = 5(f-f s ) (14) 

where 8(.) represents the Dirac delta function and f s the Doppler shift (in Hz). 

RICE ls a tap-gain process which is the sum process of the two processes CLASS and STATlC(f$), with f s 
= 0,7 each contributing half of the total power. Hence ja(t)f is Rician distributed and the PDS is: 

S (0 = S RIC£ (f ,f d ) = 0,5 S aASS (f ,f d ) + 0,5 S STATIC (f , 07f d ) (15) 

6.6.3.3 Propagation models 

In this subclause, the propagation models that are referred to in this ETS are defined. The vehicle speed x 
(in km/h), which affects f d (see subclause 6.6.3.2), is attributed to the model designation (e.g. HT200 
means Hilly Terrain for 200 km/h). 



Table 17: Propagation models 



Propagation model 


Tap 


Relative delay 


Average relative 


Tap-gain 




number 


<fs) 


power (dB) 


process 


Static 


1 


0 


0 


STATIC(O) 


Rural Area (RAx) 


1 


0 


0 


RICE 


Typical Urban (TUx) 


1 


0 


0 


CLASS 


2 


5 


-22,3 


CLASS 


Bad Urban (BUx) 


1 


0 


0 


CLASS 


2 


5 


-3,0 


CLASS 


Hilly Terrain (HTx) 


1 


0 


0 


CLASS 


2 


15 


-8,6 


CLASS 


Equaliser Test (EQx) 


1 


0 


0 


CLASS 


2 


11,6 


0 


CLASS 




3 


73,2 


-10,2 


CLASS 




4 


99,3 


-16 


CLASS 



7 Radio sub-system synchronisation 



7.1 Introduction 

This clause defines the requirements for synchronisation on the TETRA V+D radio sub-system, for carrier 
frequencies of between 380 MHz and 520 MHz. It does not define the synchronisation algorithms to be 
used in the BS and MS. These are up to the manufacturer to specify. 

7.2 General description of synchronisation system 

This subclause gives a general description of the synchronisation system. Detailed requirements are given 
in the subsequent subclauses. 

The BS sends signals on the BSCH to enable the MS to synchronise itself to the BS and if necessary 
correct its frequency standard to be in line with that of the BS. The signals sent by the BS for these 
purposes are frequency correction signals and synchronisation signals. 

The timings of timeslots, TDMA frames and multiframes are all related to a common set of counters which 
run continuously whether the MS and BS are transmitting or not (see subclause 7.3). Thus, once the MS 
has determined the correct setting of these counters, all its processes are synchronised to the current 
serving BS. 

The MS must time its transmissions to the BS in line with those received from the BS. This process is 
called "mobile timebase adjustment". 
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7.3 Timebase counters 

7.3.1 Timing counters 

The timing state of the signals transmitted by a BS or MS shall be defined by the following counters: 
Quarter symbol Number (OA/) (1 - 1020); 
Symbol Number {SN) (1 - 255); 
Timeslot Number (TN) (1 - 4); 
TDMA Frame Number (FN) (1 - 1 8); 
TDMA Multiframe Number (MN) (1 - 60). 

7.3.2 Values of the counters 

The relationship between these counters shall be as follows: 

QN increments every 125/9 //s (for an MS, this holds unless otherwise required by the mobile 

timebase adjustment); 

SN = integer part of (OA/+3)/4; 

TN increments whenever QN changes from count 1 020 to 1 ; 
FN increments whenever TN changes from count 4 to 1 ; 
MN increments whenever FN changes from 1 8 to 1 . 

The simultaneous change of state of all counters to 1 defines the timebase reference. This timebase 
reference takes into account the offset required in the case of MCCH sharing (+/- 18 frames). 

7.4 Timing of transmitted signals 

The timing of modulation symbols transmitted by the MS and BS is defined in clause 9. 

The MS may use the timing of receipt of the synchronisation burst to set-up its timebase counters. If it 
does, it shall do so as follows: 

QN shall be set by the timing of the training sequence; 

the value of TN shall be read from the BSCH, when received. In any other case, augmentation of 
TN shall be given by: 

77V: = TA/mod(4) + 1; (16) 

the value of FN shall be read from the BSCH, when received. In any other case, augmentation of 
FN shall be given by: 

FN = FN mod (18) + 1; (17) 

the value of MN is read from the BSCH, when received. In any other case, augmentation of MN 
shall be given by: 

MM = M/Vmod(60) + 1. (18) 

When BSs that differ from the current serving BS are being monitored for call re-establishment or 
handover purposes, the MS may choose to store the values of QN, TN, FN and MN for all the BSs whose 
synchronisation bursts have been detected relative to QN, TN, FN and MN for its current serving BS. 
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7.5 BS requirements for synchronisation 

The BS shall use a single frequency source with accuracy better than ± 0,2 ppm for both RF frequency 
generation and clocking the timebase. The same source shall be used for all carriers of the BS. 

It is optional whether the timebase counters of different BSs are synchronised together. 

The channels of different carriers transmitted by a BS shall be synchronised together, i.e. controlled by the 
same set of counters. The timing difference between the different carriers shall be less than 1/4 symbol 
duration. In case of timesharing of the same carrier by different BSs, the timing difference between the 
timebase references of two any such BS shall be less than 1/2 symbol duration. 

7.6 MS requirements for synchronisation 

The MS shall only transmit to the BS if the requirements of items a) to c) below are met. 

a) The MS carrier frequency shall be accurate to within ± 0,2 ppm compared to signals received from 
the BS (these signals may have an apparent frequency error due to BS frequency error and Doppler 
shift). The signals from the BS shall be averaged by the MS over sufficient time that errors due to 
noise or interference are allowed for within the above ± 0,2 ppm figure. The MS timebase shall be 
accurate to within ± 2 ppm. 

b) The MS shall adjust its internal timebase in line with that of signals received from the BS. If the MS 
determines that the timing difference exceeds 1/4 symbol duration, it shall adjust its timebase in 
steps of 1/4 symbol duration. This adjustment shall be performed at intervals of not less than 
1 second and not greater than 3 seconds until the timing difference is less than 1/4 symbol duration. 

c) In determining the timing of signals from the BS, the timings shall be assessed in such a way that 
the timing assessment error is less than 1/8 symbol duration. The assessment algorithm shall be 
such that the requirements of (b) can be met. 

The conditions under which the requirements of items a) to c) shall be met shall be 3 dB below the 
reference sensitivity level defined in clause 6 and 3 dB less carrier to interference ratio than the reference 
interference ratios defined in clause 6. Static or dynamic reference sensitivity levels shall be used 
depending on the applied propagation conditions. 

8 Channel coding 

8.1 Introduction 

A reference configuration of the TETRA transmission chain is given in clause 4. According to the 
reference configuration, this clause defines the error control process which applies to the information bits 
packed in MAC blocks (see definition in clause 19), and which provides multiplexed bits packed in 
multiplexed blocks. 

This clause applies to logical channels that are not related to speech transmission. The definition of logical 
channels is given in clause 9. 

This clause includes the specification of encoding, re-ordering and interleaving, and scrambling, but does 
not specify any data processing on the receive part. 

A definition of the error control process is provided for each kind of logical channel. 
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8.2 
8.2.1 



General 

Interfaces in the error control structure 

information bits in MAC blocks 
(1) type-1 bits in type-1 blocks 



block- 
encoding 



block-encoded bits 
(2) type-2 bits in type-2 blocks 



(3) type-3 bits in type-3 blocks 



n 
t 
e 
r 
f 
a 
c 
e 

I 

e (4) type-4 bits in type-4 blocks 

V 

e 

I 



(5) type-5 bits in type-5 blocks 



tail bits 



convolutional 
encoding 



convolutionally-encoded bits 



re-ordering/ 
interleaving 



interleaved bits 



scrambling 



scrambled bits 



to the multiplexed blocks 
Figure 8: Interfaces in the error control structure 

The definition of interfaces within the error control structure is given by figure 8. 

Each logical channel shall have its own error control scheme. For each one, the information bits 
(eventually including a MAC header) are referred to as type-1 bits. The type-1 bits are packed in MAC 
blocks (see clause 19) ( which are referred to as type-1 blocks, this defines interface (1) in figure 8. 

The processing in the transmit part shall be as follows: 

the type-1 bits shall be encoded by a block code, providing block-encoded bits. In some cases tail 
bits shall be appended to these block-encoded bits. The block-encoded bits and the tail bits (if 
added) are referred to as type-2 bits and shall be packed in a type-2 block, this defines interface 
(2); 

the type-2 bits shall be encoded by a convolutional code, which provides the convolutionally- 
encoded bits. The convolutionally-encoded bits are referred to as type-3 bits and shall be packed in 
a type-3 block, this defines interface (3); 

the type-3 bits shall be reordered and interleaved, into interleaved bits: the interleaved bits are 
referred to as type-4 bits and shall be packed in encoded blocks (see clause 19). Encoded blocks 
are referred to as type-4 blocks, this defines interface (4); 

the type-4 bits shall be scrambled, into type-5 bits, which compose type-5 blocks: this defines the 
interface (5). These bits shall then be mapped into multiplexed blocks. A multiplexed block shall be 
one of 5 different kinds: control block, BBK, synchronisation block, block-1 block, or block-2 block. 
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All these operations are made on a per type-1 block basis. The sizes of type-1 blocks and of type-5 blocks 
and multiplexed blocks depend on the logical channel with which they are associated. 



For ease of understanding, a notation for bits and blocks is given for use throughout this clause: 
x is the interface number, as defined in figure 8: x = 1 , 2, 3, 4, 5; 
n is a block number; 
Bx(n) is the type-x block number n; 
K x is the number of bits that are carried by one type-x block; 
k is a bit number; 

bx(n,k) is the type-x bit number k in the type-x block number n; 

alternatively bx(k) is the type-x bit number k in a type-x block (for ease of notation), 
with k = 1 , 2,..., K Xi and n = 1 , 2,... 

The bits of the multiplexed blocks shall be denoted as: 

cb(k): bit number k in an control block; 

bb(k): bit number k in a BBK; 

sb(k): bit number k in a synchronisation block; 

bkn1(k): bit number k \n a block-1 block; 

bkn2(k): bit number k in a block-2 block. 
8.2.3 Definition of error control codes 

8.2.3.1 16-state Rate-Compatible Punctured Convolutional (RCPC) codes 

The RCPC codes shall encode K 2 type-2 bits b 2 (1), b 2 (2),..., b 2 (K^ into K 3 type-3 bits b 3 (1), b 3 (2),..., 
b 3 (K3). This encoding shall be performed in two steps: 

encoding by a 16-state mother code of rate 1/4; 

puncturing of the mother code so to obtain a 1 6-state RCPC code of rate K^K 3 . 

A general description of these two steps is given in subclauses 8.2.3.1.1 and 8.2.3.1.2 respectively. The 
puncturing coefficients of the 16-state RCPC codes of rates 2/3, 1/3, 292/432 and 148/432 are given in 
subclauses 8.2.3.1.3, 8.2.3.1.4, 8.2.3.1.5 and 8.2.3.1.6 respectively. 

8.2.3.1 .1 Encoding by the 1 6-state mother code of rate 1/4 

The input to the mother code of any type-2 bit b 2 (k) t = 1 , 2,..., K 2t implies the output, by the mother code, 
of 4 bits, denoted by V(4(/r-1)+/) ( /= 1 , 2, 3, 4, which shall be calculated as follows. 

Any of the 4 generator polynomials of the mother code, Gj(D), / = 1 , 2, 3, 4, can be written as: 



8.2.2 



Notation 



Gi(D)= I 9 j D j , for /=1, 2,3,4; 



(19) 



where <fi 



^■="<ror 1,/= 0,1,2,3,4. 
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This means that the encoded bits are defined by: 

V(4(k -1) + i) = S t>>(k - jjgj , for /=1 ,2,3,4, and k^,2,...K 2 (20) 

where the sum is meant modulo 2, and where b 2 (k-j) - Vfor k < j. 
The generator polynomials of the mother code shall be: 

G 1 (D)=1 +D + D 4 (21) 
G 2 (D)=1 + tf + rf + D 4 (22) 
G 3 (D)=1 + Q + tf + Q A (23) 
G 4 (D)=1 + D + D? + D 4 (24) 

8.2.3.1 .2 Puncturing of the mother code 

The puncturing of the mother code into a 16-state RCPC code of rate (K^K£ is achieved by selecting K 3 
type-3 bits out of the (4 K 2 ) bits encoded by the mother code. This selection shall be as follows. 

Denoting by P(1), P(2),.., P(t) the t puncturing coefficients (each one being equal to 1, 2, 3, 4, 5, 6, 7, or 
8), the type-3 bits are given by: 

b 3 (j)= lW,for/=1,2,...,/<3, (25) 

with k = 8 ((M) div /) + P(i - <(M) div /)), 

where / and tare defined in the following puncturing schemes. 

8.2.3.1 .3 Puncturing scheme of the RCPC code of rate 2/3 
The f=3 puncturing coefficients shall be: 

P(1 ) = 1 , P(2) = 2, P{3) = 5, and /=/. (26) 

8.2.3.1 .4 Puncturing scheme of the RCPC code of rate 1/3 

The M3 puncturing coefficients shall be: 

P(1^ f P(2)=2, P(3)=3, P(4>5, P(5>6, P(6)=7, and /=/. (27) 

8.2.3.1.5 Puncturing scheme of the RCPC code of rate 292/432 

The f=3 puncturing coefficients shall be: 

Pf f>=1 , P(2)=2 t P(3)=5, and i=j+{j -1 ) div 65, with /=1 , 2 432. (28) 

8.2.3.1 .6 Puncturing scheme of the RCPC code of rate 1 48/432 
The f=6 puncturing coefficients shall be: 

P^1, P(2)=2, P(3>3, Pf4j=5, P(5)=6 t P(6)=7 f and tej+QA) div 35, 

withal, 2 432. (29) 
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8.2.3.2 



Shortened (30,14) Reed-Muller (RM) code 



The shortened (30,14) RM code shall encode 14 type-1 bits bi(1), bi(2),..., brfU) into 30 type-2 bits b 2 (1), 

b 2 (2),..., b2(30). 

The vector of the 30 type-2 bits shall be derived from 



where G is the generator matrix: 
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where I/4 denotes the (14 x 14) identity matrix. 
8.2.3.3 (Kf+16, Kj) block code 

The (K,+16, Kj) code shall encode K, type-1 bits bi(1), b,(2),..., brfK,) into 0C,+16; type-2 bits b^), 
b2(2),..., brfK^AS). The encoding rule shall be as follows (see CCITT Recommendation X.25 [1]). 

The type-1 bits are treated as the coefficients of the polynomial: 



[b 2 (1), b2(2) bz(30J\ = 1^(1), ^(2) brfUft.G 



(30) 



M(X)= Sb,(k)X 



(32) 



Let F(X) be: 




(33) 



where all operations are meant modulo 2, and G(X) is the generator polynomial of the code: 
G(X) = X 16 + X 12 + X s + 1 



(34) 



F(X) is of degree 15, with coefficients denoted by f(0), f(1 )...., fflS): 



F(X)= Sf(i)X 

1=0 



(35) 
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The K 2 type-2 bits, with K 2 = fy+16, are then given by: 
b 2 (k) = brfk), for k = 1 , 2,..., K 1t and 

b 2 (k) = ffKi+16-k), for k = Kt+1, Kj+2,..., ^+16. (36) 

8.2.4 Definition of interleaving schemes 

8.2.4.1 Block interleaving 

A (K,a) block interleaver shall re-order K 3 type-3 bits b 3 (1), b 3 (2),..., b 3 (K 3 ) into K 4 type-4 bits b 4 (1), 
b 4 (2),..., b 4 (K 4 ) t with K=K3=K 4 , in the following way: 

b 4 (k) = b 3 (i),i=1,2,...,K, (37) 
with/c= 1 + ((a */)mod K? 

8.2.4.2 Interleaving over N blocks 

Interleaving over N blocks use two steps to interleave a sequence of M type-3 blocks B 3 (1), B 3 (2),.. B 3 (M) 
of 432 bits each into a sequence of (M+N-1) type-4 blocks B 4 (1), B 4 (2),...B 4 (M+N-1) of 432 bits each, 
where M is an integer and N has values 1 , 4, or 8. This interleaving shall be as follows. 

Firstly, a diagonal interleaver interleaves the M blocks B 3 (1), B 3 (2),..B 3 (M) into (M+N-1) blocks B' 3 (1), 
B' 3 (2),.. B' 3 (M+N-1). Denoting by b' 3 (m,k) the /r-th bit of block B' 3 (m), with k = 1,2,.., 432 and m = 1, 2,..., 
M+N-1, 

b' 3 (m,k) = b 3 (m-i, j+1+(i * N)) t for 1 < m -j < M, 

b' 3 (m,k) = 0, otherwise (38) 

with /= (fc-1) div (432/A/), and /= (fr-1) mod (432/A/). 

A block interleaver then interleaves each block B' 3 (m) into type-4 block ft^mj, m = 1 , 2,. .M+N-1: 

b 4 (m,i) = b' 3 (m,k), (39) 

with fc= 1,2 432, and /= 1+ [(103 * A) mod 432]. 

8.2.5 Definition of scrambling 

8.2.5.1 Scrambling method 

Scrambling shall transform K 4 type-4 bits b 4 (1), b 4 (2) t ..b 4 (K 4 ) into K 5 type-5 bits b 5 (1), b 5 (2) $ ..b 5 (K 5 ) t with 
K$=K 4 , as follows: 

b 5 (k) = b 4 (k) + p(k) t for k = 1 , 2...., K 5 . ( 40 ) 

where the addition is meant modulo 2, and p(k) is the /c-th bit of the scrambling sequence. 

8.2.5.2 Scrambling sequence 

The scrambling sequence {p(k), k=1, 2,..., K 5 ] shall be generated from the 30 bits of the extended colour 
code e(1), e(2),.., e(30) (see clauses 19 and 23), except for the BSCH, by means of linear feedback 
registers. For the scrambling of BSCH, all bits e(1), e(2),.. f e(30) shall be set equal to zero. 
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The scrambling sequence generator shall be based upon the following connection polynomial: 



32 



c(x)= IqX' 



(41) 



i=0 



with a = 1 for / = 0, 1 , 2, 4, 5, 7, 8, 1 0, 1 1 , 1 2, 1 6, 22, 23, 26 and 32 f and c t = "0" elsewhere and where all 
operations are meant modulo 2. The resultant polynomial is therefore: 



c(x)=1 + X+X 2 + X 4 +X 5 + X 7 +X 8 + X 10 + X 11 +x 12 +x 16 + x 22 +x 23 +x 26 + x 
The k-ih bit of the scrambling sequence is given by: 
p(k)=2qp(k-i) 

i=1 



' 32 



(42) 



(43) 



with the following initialisation: 

p(k) = e(1-k), 

p(k)=1, 

8.3 Error control schemes 



for k= -29, -28,... 0, and 
for k= -31, -30. 
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Figure 9: Error control structure for V+D logical channels (part 1) 

In this subclause the error control scheme associated with each logical channel is defined. Figures 9 and 
10 give the error control structure. 
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Figure 10: Error control structure for V+D logical channels (part 2) 
Access Assignment Channel (AACH) 



One type-1 block shall contain 14 type-1 bits brfl), ^(2),..., b^U). 

A shortened (30,14) RM code (see subclause 8.2.3.2) shall encode the 14 type-1 bits into 30 type-2 bits, 
b 2 (1), b 2 (2),..., b&O). 



The type-4 bits shall be the same as the type-2 bits: 
b 4 (k) = b 2 (k) for k = 1 , 2,..., 30. 



(45) 



The 30 type-4 bits b 4 (1), b 4 (2),..., b 4 (30), compose the type-4 block for AACH. They shall be scrambled 
into bits b 5 (1), b 5 (2),... t b 5 (30) f according to subclause 8.2.5.1, with the scrambling sequence as defined in 
subclause 8.2.5.2. The multiplexed bits of the BBK shall be defined as: 

bb(k) = b 5 (k), for k = 1 , 2,..., 30. (46) 

8.3.2 Broadcast Synchronisation Channel (BSCH) 

One type-1 block shall contain 60 type-1 bits bi(1), bi(2),... t b^(60). 

A (76,60) block code shall encode the 60 type-1 bits into 76 block-encoded bits, b 2 (1), b 2 (2) t .. t b^76). This 
code is the <7C;+16, Krf block code as defined in subclause 8.2.3.3, with K>60. 

Four tail bits, b 2 (77), b 2 (78), b^79), b 2 (80), all set equal to zero, shall be appended to the 76 block- 
encoded bits. 



The resultant bits b 2 (1), b 2 (2),..., b 2 (80) shall be the type-2 bits. 
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A 16-state RCPC code with rate 2/3 (see subclause 8.2.3.1), shall encode the 80 type-2 bits into 120 type- 
3 bits, btfh *>3(2) b 3 (120). 

A (120, 11) block interleaving (see subclause 8.2.4.1) shall re-order the 120 type-3 bits into 120 type-4 
bits, b 4 (1). b 4 (2) b 4 (120). 

The 120 type-4 bits, b 4 (1), b 4 (2),... t b 4 (120) compose the type-4 block for BSCH. They shall be scrambled 
into bits b 5 (1), b 5 (2), b 5 (120), according to subclause 8.2.5.1, with the scrambling sequence as defined 
in subclause 8.2.5.2. 

The multiplexed bits of the synchronisation block shall be defined as: 

sb(k) = b 5 (k), for k = 1 , 2,..., 120. (47) 

8.3.3 Traffic channels in circuit switched mode 

In case frame stealing is activated for one of the traffic channels defined below the multiplexed bits either 
of block-1 or of block-1 and block-2 are replaced by STCH bits. This means that the bits are replaced after 
coding and interleaving. The construction of STCH bits is defined in subclause 8.3.4.1. 

In the case of multi-slot transmission, up to four low bit rate traffic channels shall be multiplexed. This is 
further described in clause 23. 

8.3.3.1 Traffic CHannel, net rate = 4,8 kbit/s (TCH/4,8) 

A sequence of M type-1 blocks, Brfm), m = 1, 2,...M, shall be transmitted, whereby Mis not limited. 

One type-1 block shall contain 288 type-1 bits, brfl), bi(2),..., ^(288). 

The K 2 = 292 type-2 bits shall comprise the 288 type-1 bits mapped as follows: 

b 2 (j) = t>i(j)> for/=1, 2 288. (48) 

with the addition of four tail bits, b 2 (289), b 2 (290), b 2 (291), b 2 (292) t all set equal to zero. 

A 16-state RCPC code with rate 292/432 (see subclause 8.2.3.1) shall encode the 292 type-2 bits into 432 
type-3 bits, b 3 (1), b 3 (2),..., b 3 (432). 

An interleaving over N blocks (see subclause 8.2.4.2) shall interleave bits from M type-3 blocks (of 432 
bits each) into (M+N-1) type-4 blocks (of 432 bits each): the bits in one type-4 block shall be denoted by 
b 4 (1), b 4 (2) t ..., b 4 (432). The parameter N shall be pre-set at the call set-up ( and may take the values 1,4, 
or 8. 

The 432 type-4 bits b 4 (1), b 4 (2),..., b 4 (432) shall compose the type-4 block for TCH/4,8. They shall be 
scrambled into bits bs(1), bs(2),..., b 5 (432), according to subclause 8.2.5.1, with the scrambling sequence 
as defined in subclause 8.2.5.2. 

The multiplexed bits of block-1 are defined as: 

bknl (k) = b 5 (k), for k = 1 , 2,..., 216, (49) 

and the multiplexed bits of block-2 are defined as: 

bkn2(k) = b 5 (k+216), for k= 1 , 2,..., 216. (50) 

8.3.3.2 Traffic CHannel, net rate = 2,4 kbit/s (TCH/2,4) 

A sequence of M type-1 blocks, Brfm), m = 1, 2,...M, shall be transmitted, whereby Mis not limited. 
One type-1 block shall contain 144 type-1 bits, bi(1), bi(2),.„, ^(144). 



Page 70 

ETS 300 392-2: March 1996 

The K 2 = 148 type-2 bits shall comprise the 144 type-1 bits mapped as follows: 

b 2 G) = b 1 (i), fory=1,2,...,144, (51) 

with the addition of four tail bits, b 2 (145), b 2 (146), b 2 (U7), b 2 (148), all set equal to zero. 

A 16-state RCPC code with rate 148/432 (see subclause 8.2.3.1) encodes the 148 type-2 bits into 432 
type-3 bits, b 3 (1), b 3 (2),..., b 3 (432). 

An interleaving over N blocks (see subclause 8.2.4.2) shall interleave bits from M type-3 blocks (of 432 
bits each) into (M+N-1) type-4 blocks (of 432 bits each): the bits in one type-4 block shall be denoted by 
b 4 (1), b 4 (2),..., b 4 (432). The parameter N shall be pre-set at the call set-up, and may take the values 1, 4, 
or 8. 

The 432 type-4 bits b 4 (1), b 4 (2),... t b 4 (432) shall compose the type-4 block for TCH/2,4. They shall be 
scrambled into bits b 5 (1), b 5 (2),..., b 5 (432), according to subclause 8.2.5.1 , with the scrambling sequence 
as defined in subclause 8.2.5.2. 

The multiplexed bits of block-1 are defined as: 

bkn1(k) = b 5 (k) % for k = 1 , 2 216, (52) 

and the multiplexed bits of block-2 are defined as: 

bkn2(k) = b 5 (k+216), for k = 1 , 2,..., 216. (53) 

8.3.3.3 Traffic CHannel, net rate = 7,2 kbit/s (TCH/7,2) 

A sequence of M type-1 blocks, Bi(m), m = 1 , 2... .M, shall be transmitted, whereby M is not limited. 
One type-1 block shall contain 432 type-1 bits, b, (1), ^(2),..., ^(432). 
There shall be 432 type-4 bits, which are the same as the type-1 bits: 

b 4 (k) = brfk), for k = 1 , 2 432. (54) 

The 432 type-4 bit b 4 (1), b 4 (2),..., b 4 (432) shall compose the type-4 block for TCH/7,2. They shall be 
scrambled into bits b 5 (1), b 5 (2),... t b 5 (432), according to subclause 8.2.5.1, with the scrambling sequence 
as defined in subclause 8.2.5.2. 

The multiplexed bits of block-1 shall be defined as: 

bkn1(k) = brfk), for k= 1, 2,..., 216, (55) 

and the multiplexed bits of block-2 shall be defined as: 

bkn2(k) = bs(k+216), for k = 1 , 2,..., 21 6. (56) 

8.3.4 Signalling channels for signalling and packet mode data 

8.3.4.1 Signalling CHannel for mapping onto Half-bursts on the Downlink (SCH/HD), 

Broadcast Network CHannel (BNCH), and STealing CHannel (STCH) 

One type-1 block shall contain 124 type-1 bits, brfl), bi(2),.„, b 1 (124). 

A (140,124) block code shall encode the 124 type-1 bits into 140 block-encoded bits b 2 (1), 
b 2 (2),...b 2 (140). This code shall be the (K^+16, Krf block code as defined in subclause 8.2.3.3, with K 7 = 
124. 

Four tail bits, b 2 (141), b 2 (142), b 2 (143), b^44) % all set equal to zero, shall be appended to the 140 block- 
encoded bits. 
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The resultant bits b 2 (1), b^),..., b 2 (144) shall be the type-2 bits. 

A 16-state RCPC code with rate 2/3 (see subclause 8.2.3.1) shall encode the 144 type-2 bits into 216 
type-3 bits, btf), b 3 (2) b 3 (216). 

A (216,101) block interleaver (see subclause 8.2.4.1) shall re-order the 216 type-3 bits into 216 type-4 
bits, b 4 (1), b 4 (2) b 4 (216). 

The 216 type-4 bits b 4 (1), b 4 (2) b 4 (216) shall compose the type-4 block for SCH/HD, BNCH, and 

STCH. They shall be scrambled into bits b 5 (1), b 5 (2), b 5 (216), according to subclause 8.2.5.1, with the 
scrambling sequence as defined in subclause 8.2.5.2. 

The type-5 bits may be multiplexed onto block-1 , in which case the multiplexed bits are defined as: 

bkn1(k) = b 5 (k), for *= 1.2 216. (57) 

or they may be multiplexed into block-2, in which case the multiplexed bits shall be defined as: 

bkn2(k) = b 5 (k), for k = 1 , 2 216. (58) 

8.3.4.2 Signalling CHannel for mapping onto Half-bursts on the Uplink (SCH/HU) 
One type-1 block shall contain 92 type-1 bits bi(1), bi(2),..., ^(92). 

A (108,92) block code shall encode the 92 type-1 bits into 108 block-encoded bits, b 2 (1), b 2 (2),...b 2 (108). 
This code is the (^+16, Krf block code as defined in subclause 8.2.3.3, with K>92. 

Four tail bits, b 2 (109), b 2 (110), b 2 (111), b 2 (112), all set equal to zero, shall be appended to the 108 block- 
encoded bits. 

The resultant bits b 2 (1) f b^2) t ... t b 2 (1 12) shall be the type-2 bits. 

A 16-state RCPC code with rate 2/3 (see subclause 8,2.3.1) shall encode the 112 type-2 bits into 168 
type-3 bits, b 3 (1), b 3 (2),..., b 3 (168). 

A (168, 13) block interleaver (see subclause 8.2.4.1) shall re-order the 168 type-3 bits into 168 type-4 bits, 
b 4 (1), b 4 (2) b 4 (168). 

The 168 type-4 bits b 4 (1), b 4 (2),..., b 4 (168) shall compose the type-4 block for SCH/HU. They shall be 
scrambled into bits b 5 (1), b 5 (2), b 5 (21 6), according to subclause 8.2.5.1 , with the scrambling sequence 
as defined in subclause 8.2.5.2. 

The multiplexed bits of the control block (which is the type-5 block for SCH/HU) are defined as: 

cb(k) = b 5 (k), for k = 1 , 2,..., 168. (59) 

8.3.4.3 Signalling CHannel for mapping onto Full bursts (SCH/F) 
One type-1 block shall contain 268 type-1 bits, btf), b^2) ^(268). 

A (284,268) block code shall encode the 268 type-1 bits into 284 block-encoded bits b 2 (1), 
b 2 (2),...b 2 (284). This code shall be the <7C;+f 6, Krf block code as defined in subclause 8.2.3.3, with = 
268. 

Four tail bits, b 2 (285), b 2 (286) t b 2 (287), b 2 (288) t all set equal to zero, shall be appended to the 284 block- 
encoded bits. 

The resultant bits brfl), b^2) t ... t b 2 (288) shall be the type-2 bits. 

A 16-state RCPC code with rate 2/3 (see subclause 8.2.3.1) encodes the 288 type-2 bits into 432 type-3 
bits, btf), b 3 (2) b 3 (432). 



Page 72 

ETS 300 392-2: March 1996 

A (432,103) block interleaver (see subclause 8.2.4.1) shall re-order the 432 type-3 bits into 432 type-4 
bits, b 4 (1), b 4 (2) b 4 (432). 

The 432 type-4 bits b 4 (1), b 4 (2),..., b 4 (432) shall compose the type-4 block for SCH/F. They shall be 
scrambled into bits bs(1), bs(2), bs(432), according to subclause 8.2.5.1, with the scrambling sequence 
as defined in subclause 8.2.5.2. 

The multiplexed bits of block-1 are defined as: 

bkn1(k) = b 5 (k), for lr= 1, 2 216. (60) 

and the multiplexed bits of block 2 are defined as: 

bkn2(k) = b 5 (k+216), for k = 1 , 2,..., 216. (61) 

9 Channel multiplexing for V+D 

9.1 Introduction 

This clause defines the physical channels of the V+D radio sub-system required to support the logical 
channels. It includes a description of the logical channels and the definitions of TDMA frames, timeslots 
and bursts. 

9.2 Logical channels 

A logical channel is defined as a logical communication pathway between two or more parties. The logical 
channels represent the interface between the protocol and the radio subsystem. 

The definition of the logical channels that are supported by the radio subsystem is given below. 

9.2.1 Logical channels hierarchy 

The logical channels may be separated into two categories: the traffic channels carrying speech or data 
information in circuit switched mode and the control channels carrying signalling messages and packet 
data. The logical channels supported by the MAC are described here, with their hierarchical relationship. 

9.2.2 Traffic channels 

The traffic channels shall carry user information. Different traffic channels are defined for speech or data 
applications and for different data message speeds: 

Speech Traffic Channel (TCH/S). 

Circuit mode traffic channels as follows: 

7,2 kbit/s net rate (TCH/7.2); 
4,8 kbit/s net rate (TCH/4.8); 
2,4 kbit/s net rate (TCH/2.4) . 

Higher net rate up to 28,8, 19,2 or 9,6 kbit/s may be used. They are obtained by allocating up to 4 TP 
channels to the same communication. 

NOTE: Three different depths of interleaving (with N = 1 , 4, or 8) may be applied to the traffic 
channels TCH/4.8 and TCH/2.4 as detailed in subclause 8.2.4.2. 
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9.2.3 Control CHannels (CCH) 

9.2.3.1 General 

The CCH shall carry signalling messages and packet data. Five categories of control channel are defined: 
Broadcast Control CHannel (BCCH); 
Linearisation CHannel (LCH); 
Signalling CHannel (SCH); 
Access Assignment CHannel (AACH); and 
STealing CHannel (STCH). 

9.2.3.2 BCCH 

The BCCH shall be a uni-directional channel for common use by all MSs. It shall broadcast general 
information to all MSs. 

Two categories of BCCHs are defined, network and synchronisation: 

Broadcast Network Channel (BNCH): 

down-link only, broadcasts network information to MSs; 

Broadcast Synchronisation Channel (BSCH): 

down-link only, broadcast information used for time and scrambling synchronisation of the 
MSs. 

9.2.3.3 LCH 

The LCH shall be used by the base and MSs to linearize their transmitter. 
Two categories of LCHs are defined, common and BS: 
Common Linearisation Channel (CLCH): 

up-Iink, shared by all the MSs; 
BS Linearisation CHannel (BLGH) : 
downlink, used by the BS. 

9.2.3.4 SCH 

The SCH shall be shared by all MSs, but may carry messages specific to one or one group of MSs. 
System operation requires the establishment of at least one SCH per BS. SCH may be divided into 3 
categories, depending on the size of the message: 

Full size Signalling Channel (SCH/F): 

bi-directional channel used for full size messages; 
Half size Downlink Signalling Channel (SCH/HD): 

downlink only, used for half size messages; 
Half size Uplink Signalling Channel (SCH/HU): 

uplink only, used for half size messages. 
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9.2.3.5 AACH 

The AACH shall be present on all transmitted downlink slots. It shall be used to indicate on each physical 
channel the assignment of the uplink and downlink slots. The AACH shall be internal to the MAC. 

9.2.3.6 STCH 

The STCH is a channel associated to a TCH that temporarily -steals" a part of the associated TCH 
capacity to transmit control messages. It may be used when fast signalling is required. In half duplex 
mode the STCH is unidirectional and has the same direction as the associated TCH. It may be used when 
fast signalling is required. 

9.3 The physical resource 

9.3.1 General 

The physical resource available to the radio sub-system is an allocation of part of the radio spectrum. This 
resource shall be partitioned both in frequency and time. Frequency shall be partitioned by RF channels 
divided into bands as defined in clause 6. Time shall be partitioned by timeslots and TDMA frames as 
defined in this subclause. 

The access scheme shall be TDMA. 

The TDMA structure shall be composed of hyperframes, multiframes, frames, slots and subslots. 
Figure 1 1 repeats the representation of the TDMA structure given in figure 2. 

9.3.2 RF channels 

A RF channel is defined as a specified portion of the RF spectrum. Clause 6 defines the carrier separation 
which applies to TETRA channels. 

The DownLink (DL) comprises RF channels used in the BS to MS direction. 
The UpLink (UL) comprises RF channels used in the MS to BS direction. 

One pair of radio frequencies (uplink and downlink) of the cell allocation shall be used to carry the MCCH 
(see subclauses 9.4.2.1 and 9.5.1) and shall be known as the main carrier. 
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Figure 1 1 : TDMA structure 



9.3.3 Timeslots 

The basic unit of the TDMA structure is the timeslot. A timeslot shall have a duration of 85/6 ms 
(approximately 14,17 ms) which corresponds to 510 modulation bits duration. 

9.3.4 TDMA frame 

Four timeslots shall form a TDMA frame. The TDMA frame has a duration of 170/3 ms (approximately 
56,67 ms). 

The TDMA frames shall be numbered by a Frame Number (FN). The FN shall be cyclically numbered 
from 1 to 18. The FN shall be incremented at the end of each TDMA frame. 

The frame FN18 (also termed the control frame) shall be exclusively devoted to control channels. 

9.3.5 Timeslot numbering 

The timeslots within a TDMA frame shall be numbered from 1 to 4 and a particular timeslot shall be 
referenced by its Timeslot Number (TN). 

9.3.6 Subslot 

The uplink timeslots may be divided into 2 subslots. The subslots within a timeslot shall be numbered from 
1 to 2 and a particular subslot shall be referenced by its SubSlot Number (SSN). 

A subslot shall have a duration of 85/12 ms (approximately 7,08 ms) which corresponds to 255 modulation 
bits duration. 
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9.3.7 Multiframe 

Eighteen TDMA frames shall form a multiframe. The multiframe shall have a duration of 1 ,02 s. 

The multiframes shall be numbered by a Multiframe Number (MN). The MN shall be cyclically numbered 
from 1 to 60. The MN shall be incremented whenever the TDMA FN returns to 1 . 

9.3.8 Hyperframe 

The hyperframe shall be the longest recurrent time period of the TDMA structure. Sixty multiframes shall 
form a hyperframe. The hyperframe shall have a duration of 61 ,2 s. 

9.3.9 Frame alignment 

At the BS, the start of the hyperframe, multiframe and TDMA frame on the uplink shall be delayed by the 
fixed period of 2 timeslots from the start of the hyperframe, multiframe and TDMA frame on the downlink. 

9.4 Physical channels 

9.4.1 General 

A physical channel is defined by a pair of radio carrier frequencies (downlink and uplink) and a TN. There 
shall be 4 physical channels per pair of radio frequencies. 

9.4.2 Types of physical channels 

Three types of physical channel are defined: 

the Control Physical channel; 

the Traffic Physical channel; and 

the Unallocated Physical channel. 
The type of physical channel shall be indicated in the AACH. 

9.4.2.1 CP channel 

The CP channel is a physical channel carrying exclusively CCH. Two types of CP channels are defined: 

the Main Control CHannel (MCCH); and 

the Secondary Control CHannel (SCCH). 

In each cell one RF carrier shall be defined as the main carrier. Whenever a MCCH is used, the MCCH 
shall be located on the timeslot 1 of the main carrier. 

The SCCH may be used to extend the signalling capacity of the MCCH and may only be assigned when 
the MCCH is used. 

9.4.2.2 TP channel 

The TP channel is a physical channel carrying TCH. 

9.4.2.3 UP channel 

The UP channel is a physical channel not allocated to one or more MS. 
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9.4.3 Bursts 

9.4.3.1 General 

A burst is a period of RF carrier that is modulated by a data stream. A burst therefore represents the 
physical content of a timeslot or subslot. 

The description of a physical channel will be made in terms of timeslots and TDMA frames and not in 
terms of bursts. This is because there is not a one-to-one mapping between a particular physical channel 
and the use of a particular burst. 

A given physical channel shall use the same timeslot number in every TDMA frame. 

9.4.3.2 Modulation symbol numbering 

A timeslot shall be divided into 255 modulation symbol durations, each one with a duration of 1/18 ms 
(approximately 55,56 //s). A particular modulation symbol within a burst shall be referenced by a Symbol 
Number (S/V), with the first modulation symbol numbered SN1 and the last modulation symbol numbered 
SNmax. 

Different types of bursts are defined, having different durations. 

At the beginning of the transmission of a single burst or of consecutive bursts, a supplementary symbol 
SNO is defined. It does not carry information but shall be used as phase reference for the differential 
modulation. 

9.4.3.3 Modulation bit numbering 

In the following sections the content of the burst is defined in terms of modulation bits. 

A particular modulation bit within a burst shall be referenced by a Bit Number (BN), with the first 
modulation bit numbered BN1 and the last modulation bit numbered BNmax. At the modulator the 
modulation bits shall be grouped in pairs of consecutive odd and even numbered bits and each pair shall 
be converted into one modulation symbol as described in clause 5. 

9.4.3.4 Burst timing 

The symbol time is defined as the instant at which the transmitted symbol waveform is at a maximum for 
the symbol of interest. The timing of a modulation symbol is determined by its symbol time. 

The bits BN(2n-1) and BN(2n) shall determine the symbol SN(n) and the symbol time of the modulation 
symbol SN(n) shall be delayed by (n+d) modulation symbol durations with respect to the start of the slot, 
with: 

n: integer (1 ... (SA/max)); 

d is defined as the burst delay. The burst delay represents the delay between the start of the 
timeslot and the symbol time of the symbol SN1. The burst delay shall be expressed in modulation 
symbol duration and varies with the type of burst and the SSN. The values of the burst delays are 
given in table 18. 

The symbol time of the symbol SNO occurs one modulation symbol duration before the symbol time of the 
symbol SN1 of the first burst of a transmission. 

9.4.4 Type of bursts 
9.4.4.1 General 

Eight types of bursts shall exist in the system. Figure 12 summarises the description of the bursts and 
their timing with respect to the timeslot. 
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Figure 12: Types of bursts 
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Table 18: Burst types 



Burst type 


SNmax 


d burst delay (in symbol 
duration) 


Bit allocation 






SSN1 


SSN2 




control uplink 


103 


17 


144,5 


see subclause 
9.4.4.2.1 


linearization uplink 


not applicable 


120 


not allowed 


see subclause 
9.4.4.2.2 


linearization downlink 


not applicable 


not allowed 


not applicable 


see subclause 
9.4.4.2.3 


normal uplink 


231 


17 


see subclause 
9.4.4.2.4 


normal continuous downlink 


255 


0 


see subclause 
9.4.4.2.5 


synchronisation 
continuous downlink 


255 


0 


see subclause 
9.4.4.2.6 


normal 

discontinuous downlink 


246 


5 


see subclause 
9.4.4.2.7 


synchronisation 
discontinuous downlink 


246 


5 


see subclause 
9.4.4.2.8 



The generic name for normal continuous and discontinuous downlink burst is Normal Downlink Burst 
(NDB). The generic name for synchronisation continuous and discontinuous downlink burst is 
Synchronisation downlink Burst (SB). 



9.4.4.2 Modulation bits allocation 

The bursts are divided into burst fields containing contiguous modulation bits of the same type. The burst 
fields are described in subclause 9.4.4.3. 

The downlink bursts contain 3 independent blocks, called Broadcast Block (BBK), Block 1 (BKN1) and 
Block 2 (BKN2). The normal uplink bursts contains two independent blocks, called Block 1 (BKN1) and 
Block 2 (BKN2). A separate logical channel may be mapped on each block. The broadcast block shall be 
made of the two scrambled broadcast bits fields and shall contain 30 bits. The block 1 and block 2 shall 
be made of one field and shall contain 216 scrambled bits. In the case of synchronisation bursts, block 1 
contains 120 bits. 

9.4.4.2.1 Control uplink Burst (CB) 

The allocation of the modulation bits in the CB shall be in accordance with table 19. The CB shall be used 
by MS to transmit control messages to the BS. 



Table 19: Control uplink Burst (CB) 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 4 


4 


tail bits 


t1 to t4 


see subclause 
9.4.4.3.5 


5 to 88 


84 


scrambled control bits 


c«1)toc#84) 


see clause 8 


89 to 118 


30 


extended training sequence 


x1 to x30 


see subclause 
9.4.4.3.3 


119 to 202 


84 


scrambled control bits 


c«85) tocfc(168) 


see clause 8 


203 to 206 


4 


tail bits 


t1 to t4 


see subclause 
9.4.4.3.5 



9.4.4.2.2 Linearisation uplink Burst (LB) 

The LB may be used by the MSs to linearize their transmitters. The LB contains no useful bits and its 
timing shall only be determined by the time mask (see clause 6). 
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9.4.4.2.3 Linearisation downlink burst 

The linearization downlink burst replaces BKN2 of either a normal continuous downlink burst or a 
synchronisation continuous downlink burst. 

The linearization downlink burst may be used by the BS to linearize its transmitter. The linearization 
downlink burst contains non useful bits and its timing shall be determined only by the time mask (see 
clause 6). 

9.4.4.2.4 Normal Uplink Burst (NUB) 

The allocation of the modulation bits in the NUB shall be in accordance with table 20. The NUB shall be 
used by MSs to transmit control or traffic messages to the BS. 



Table 20: Normal Uplink Burst (NUB) 



Bit Number 
(BN) 


Field 
length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 4 


4 


tail bits 


1 1 to t4 


see subclause 
9.4.4.3.5 


5 to 220 


216 


scrambled block 1 bits 


MnT(1)to Wcnf(216) 


see clause 8 


221 to 242 


22 


normal training sequence 


n1Xo n22 or pUo p22 


see subclause 
9.4.4.3,2 


243 to 458 


216 


scrambled block 2 bits 


bknZA) to bkn2(2^6) 


see clause 8 


459 to 462 


4 


tail bits 


t1 to 14 


see subclause 
9.4.4.3.5 



9.4.4.2.5 Normal continuous downlink burst 



The allocation of the modulation bits in the normal continuous downlink burst shall be in accordance with 
table 21. The normal continuous downlink burst shall be used by the BS in continuous transmission mode 
to transmit control or traffic messages to the MS. 



Table 21: Normal continuous downlink burst 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 12 


12 


normal training sequence 3 


q11ioq22 


see subclause 
9.4.4.3.2 


13 to 14 


2 


phase adjustment bits 


haUo ha2 


see subclause 
9.4.4.3.6 


15 to 230 


216 


scrambled block 1 bits 


bkn1C\)\o Mn7(216) 


see clause 8 


231 to 244 


14 


scrambled broadcast bits 


bWDto bbtfA) 


see clause 8 


245 to 266 


22 


normal training sequence 


n1 to n22 or p1Xop22 


see subclause 
9.4.4.3.2 


267 to 282 


16 


scrambled broadcast bits 


WX15) \obb(30) 


see clause 8 


283 to 498 


216 


scrambled block 2 bits 


Wcn2(1)toWcn#216) 


see clause 8 


499 to 500 


2 


phase adjustment bits 


hb1 to hb2 


see subclause 
9.4.4.3.6 


501 to 510 


10 


normal training sequence 3 


q1 to q10 


see subclause 
9.4.4.3.2 
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9.4.4.2.6 Synchronisation continuous downlink burst 

The allocation of the modulation bits in the synchronisation continuous downlink burst shall be in 
accordance with table 22. The synchronisation continuous downlink burst shall be used by BSs in 
continuous transmission mode to broadcast synchronisation messages and to transmit control messages 
to the MSs. 



Table 22: Synchronisation continuous downlink burst 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 12 


12 


normal training sequence 3 


q11\oq22 


see subclause 
9.4.4.3.2 


13 to 14 


2 


phase adjustment bits 


hd to hc2 


see subclause 
9.4.4.3.6 


15 to 94 


80 


frequency correction 


f1 to f80 


see subclause 
9.4.4.3.1 


95 to 214 


120 


scrambled synchronisation block 1 
bits 


sfc(1)tos/?(120) 


see clause 8 


215 to 252 


38 


synchronisation training sequence 


y1 to y38 


see subclause 
9.4.4.3.4 


253 to 282 


30 


scrambled broadcast bits 


MtfDto bb{30) 


see clause 8 


283 to 498 


216 


scrambled block 2 bits 


bkn2(A)Xo 
Mn2(216) 


see clause 8 


499 to 500 


2 


phase adjustment bits 


hd1 to hd2 


see subclause 
9.4.4.3.6 


501 to 510 


10 


normal training sequence 3 


q1 to q10 


see subclause 
9.4.4.3.2 



9.4.4.2.7 Normal discontinuous downlink burst 

The allocation of the modulation bits in the normal discontinuous downlink burst shall be in accordance 
with table 23. The normal discontinuous downlink burst shall be used by BS in timesharing transmission 
mode to transmit control or traffic messages to the MS. 



Table 23: Normal discontinuous downlink burst 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 2 


2 


normal training sequence 3 


q21 to q22 


see subclause 
9.4.4.3.2 


3 to 4 


2 


phase adjustment bits 


hg1 to hg2 


see subclause 
9.4.4.3.6 


5 to 220 


216 


scrambled block 1 bits 


bknltf) \o bknlWS) 


see clause 8 


221 to 234 


14 


scrambled broadcast bits 


MXU to bbCU) 


see clause 8 


235 to 256 


22 


normal training sequence 


nUo n22 or p1top22 


see subclause 
9.4.4.3.2 


257 to 272 . 


16 


scrambled broadcast bits 


bbtfS) to bb(30) 


see clause 8 


273 to 488 


216 


scrambled block 2 bits 


bkn2^)\o bkn2(216) 


see clause 8 


489 to 490 


2 


phase adjustment bits 


hh1 to hh2 


see subclause 
9.4.4.3.6 


491 to 492 


2 


normal training sequence 3 


q1 to q2 


see subclause 
9.4.4.3.2 
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9.4.4.2.8 Synchronisation discontinuous downlink burst 

The allocation of the modulation bits in the synchronisation discontinuous downlink burst shall be in 
accordance with table 24. The synchronisation discontinuous downlink burst shall be used by the BS in 
timesharing transmission mode to broadcast synchronisation messages and to transmit control messages 
to the MS. 



Table 24: Synchronisation discontinuous downlink burst 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 2 


2 


normal training sequence 3 


q21 to q22 


see subclause 
9.4.4.3.2 


3 to 4 


2 


phase adjustment bits 


hi1 to hi2 


see subclause 
9.4.4.3.6 


5 to 84 


80 


frequency correction 


f1 to f80 


see subclause 
9.4.4.3.1 


85 to 204 


120 


scrambled synchronisation block 1 
bits 


a£>(1)tos/>(120) 


see clause 8 


205 to 242 


38 


synchronisation training sequence 


y1 to y38 


see subclause 
9.4.4.3.4 


243 to 272 


30 


scrambled broadcast bits 


bM)\obb(30) 


see clause 8 


273 to 488 


216 


scrambled block 2 bits 


bkn2(l)\o 
Wm2(216) 


see clause 8 


489 to 490 


2 


phase adjustment bits 


hj1 to hj2 


see subclause 
9.4.4.3.6 


491 to 492 


2 


normal training sequence 3 


q1 to q2 


see subclause 
9.4.4.3.2 



9.4.4.3 Burst fields 



9.4.4.3.1 Frequency correction field 

The frequency correction field shall contain 80 bits: 

(f1J2, ffl) = (1,1 ...... 1); (62) 

(®, f10, 172) = (0, 0 0); (63) 

(f73,f74,...,f80) = (1,1, 1). (64) 

The frequency correction field generates an un-modulated carrier at 2,25 kHz above the nominal carrier 
frequency, preceded and followed by a short period (4 symbol durations) of un-modulated carrier at 
6,75 kHz below the nominal carrier frequency. 

9.4.4.3.2 Normal training sequence 

Three 22 bit normal training sequences are defined. 

The first two normal training sequences shall be used on the normal uplink and downlink bursts. The type 
of training sequence shall be used as a flag indicating the presence of one or two logical channels on the 
blocks 1 and 2 of the burst, according to table 25. 
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Table 25: Training sequence mapping to logical channels 



Normal training sequence 


Logical channel 


1 


TCH 




SCH/F 


2 


STCH + TCH 




STCH + STCH 




SCH/HD + SCH/HD 




SCH/HD + BNCH 



The third training sequence shall be a supplementary training sequence spread over two consecutive 
downlink burst. 

The normal training sequence 1 shall be: 

(n1, n2,..., n22) = (1 ,1 , 0,1 , 0,0, 0,0, 1 ,1 , 1 ,0, 1 ,0, 0,1 , 1 ,1 , 0,1 , 0,0). (65) 
The normal training sequence 2 shall be: 

(p1, p2,..., p22) = (0,1 , 1 ,1 , 1 ,0, 1 ,0, 0,1 , 0,0, 0,0, 1 ,1 , 0,1 , 1 ,1 , 1 ,0). (66) 
The normal training sequence 3 shall be: 

(q1, q2,..., q22) = (1 ,0, 1 ,1 , 0,1 , 1 ,1 , 0,0, 0,0, 0,1 , 1 ,0, 1 ,0, 1 ,1 , 0,1 ). (67) 
9.4.4.3.3 Extended training sequence 

The extended training sequence shall be a 30 bit synchronisation word used for the uplink control burst. 
The extended training sequence shall be: 



(x1, x2,... t x30) = (1 ,0, 0,1 , 1 ,1 , 0,1 , 0,0, 0,0, 1 ,1 , 1 ,0, 1 ,0, 0,1 , 1 ,1 , 
0,1,0,0, 0,0,1,1). 



(68) 



9.4.4.3.4 



Synchronisation training sequence 



The synchronisation training sequence shall be a 38 bit synchronisation word used for the synchronisation 
downlink burst. 



The synchronisation training sequence shall be: 

(y1, y2,..., y38) = (1,1, 0,0, 0,0, 0,1 , 1 ,0, 0,1 , 1 ,1 , 0,0, 1 ,1 , 1 ,0, 1 ,0, 
0,1,1,1,0,0, 0,0, 0,1,1,0, 0,1,1,1). 



(69) 



9.4.4.3.5 



Tail bits 



The tail bit field shall contain 4 bits used for reducing the effect of filter transient response at the beginning 
and end of the bursts and for equalisation purposes. 



The contents of the tail bit field shall be: 

(/7, £2, f3,f4) = (1,1,0, 0). 

9.4.4.3.6 Phase adjustment bits 



(70) 



The phase adjustment bits shall be used on the downlink bursts to provide a known phase relationship 
between the different training sequences of the burst, whatever is the content of the blocks. 
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The value of the pair of phase adjustment bits shall be set so that the phase shift D<f> they generate (see 
clause 5) is equal to: 

D0 = - £D0(n) (71) 

n=n1 

where: D</)(n) is the phase transition generated by the bits (BN(2n-1), BN(2n)), n1 and n2 

are given by table 26 with respect to the bit numbering of subclause 9.4.4.2. 



Table 26: Phase adjustment bits 



phase adjustment bits 


n1 


n2 


(ha1, ha2) 


8 


122 


(hb1, hb2) 


123 


249 


(hd, hc2) 


8 


108 


(hd1, hd2) 


109 


249 


(he1 t he2) 


112 


236 


(hf1, hf2) 


1 


111 


(hg1, hg2) 


3 


117 


(hh1, hh2) 


118 


244 


(hi1, h\2) 


3 


103 


(hit hj2) 


104 


244 



9.4.5 Transmission modes 

9.4.5.1 BS continuous transmission 

When the BS is in continuous transmission mode normal downlink bursts or synchronisation bursts shall 
be transmitted on all unused downlink slots of the main carrier and may be transmitted on the unallocated 
physical channels of the other carriers. 

On the main carrier the BS shall only be allowed to ramp down and up during a BLCH. On the other 
carriers the BS may ramp down and up during the slots of an UP channel. 

The first burst after ramp up of a D-CT shall be preceded by a start burst {SNmax=5), according to 
table 27. 



Table 27: Start burst 



Bit Number 
(BN) 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 10 


10 


normal training sequence 3 


q1 to q10 


subclause 9.4.4.3.2 



The last burst before ramp down of a D-CT shall be followed by a stop burst (SNmax=6), according to 
table 28. 



Table 28: Stop burst 



Bit Number 
(BN) 


Field length 
(bits) 


field content 


field bits number 


definition 


1 to 12 


12 


normal training sequence 3 


q1Uoq22 


subclause 9.4.4.3.2 



9.4.5.2 BS timesharing transmission 

The BS in timesharing transmission mode need not to ramp down and up between adjacent discontinuous 
downlink bursts. In the case where the BS does not perform the ramping, the discontinuous burst shall be 
followed by 8 bits (corresponding to the guard period) according to table 29, and the subsequent burst 
shall be preceded by 10 bits (corresponding to the ramp up and linearization period) according to table 30. 
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Table 29: Bits following the burst 



Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 8 


8 


normal training sequence 3 


q3 to q10 


subclause 9.4.4.3.2 


Table 30: Bits preceding the burst 


Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 10 


10 


normal training sequence 3 


q11ioq20 


subclause 9.4.4.3.2 



9.4.5.3 MS multiple slot transmission 

The MS transmitting on more than 1 physical channel need not to ramp down and up between adjacent 
normal uplink bursts. In the case where the MS does not perform the ramping, the burst shall be followed 
by 14 bits (corresponding to the guard period) defined in table 31 and the subsequent burst shall be 
preceded by 34 bits (corresponding to the ramp up and linearization period), according table 32. 



Table 31 : Bits following the burst 



Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 2 


2 


phase adjustment bits 


he1 to he2 


subclause 9.4.4.3.6 


3 to 4 


2 


tail bits 


t1 \ot2 


subclause 9.4.4.3.5 


5 to 14 


10 


normal training sequence 3 


q1 to q10 


subclause 9.4.4.3.2 



Table 32: Bits preceding the burst 



Bit number 


Field length 
(bits) 


Field content 


Field bits number 


Definition 


1 to 30 


30 


extended training sequence 


x1 to x30 


subclause 9.4.4.3.3 


31 to 32 


2 


tail bits 


t3Xot4 


subclause 9.4.4.3.5 


33 to 34 


2 


phase adjustment bits 


hf1 to hf2 


subclause 9.4.4.3.6 
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9.5 Mapping of logical channels into physical channels 
9.5.1 General mapping of logical channels 

Table 33 defines the mapping in time of logical channels into physical channel types. 



Table 33: Mapping of logical channel into physical channels 



Logical 


Dire- 


Burst 


SSN/ 


Physical 


FN 


TN 


channel 


ction 


type 


Block 


channel 






BSCH 


DL 


SB 


BKN1 


CP, TP 


18 


4-(MA/+1)mod4# 








BKN1 


UP 


1...18 


1-4 


BNCH 


DL 


NDB 


BKN2 


CP.TP 


18 


4-(M/V+3)mod4# 






NDB 


BKN2 


CP 


1...18 


1-4 






SB 


BKN2 


UP 


1...18 


1-4 


AACH 


DL 


NDB, SB 


BBK 


CP, TP, UP 


1—18 


1-4# 


BLCH 


DL 


NDB.SB 


BKN2 


CP, UP 


1...18 


1-4 










TP 


18 


1-4 


CLCH 


UL 


LB 


SSN1 


CP, TP 


18 


4-(MA/+1)mod4# 








SSN1 


CP, UP 


1-18 


1-4 


SCH/F 


DL 


NDB 


BKN1+BKN2 


CP 


1—18 


1-4 










TP 


18 


1-4 




UL 


NUB 


BKN1+BKN2 


CP 


1—18 


1-4 










TP 


18 


1-4 


SCH/HD 


DL 


NDB, SB 


BKN1, BKN2 


CP, UP 


1—18 


1-4 










TP 


18 


1-4 


SCH/HU 


UL 


CB 


SSN1, SSN2 


CP 


1—18 


1-4 










TP 


18 


1-4 


TCH 


DL 


NDB 


BKN1, BKN2 


TP 


1—17 


1-4 




UL 


NUB 


BKN1, BKN2 


TP 


1-17 


1-4 


STCH 


DL 


NDB 


BKN1, BKN2 


TP 


1-17 


1-4 




UL 


NUB 


BKN1, BKN2 


TP 


1-17 


1-4 


NOTE: 


# indicates a mandatory mapping. 









The mapping shall be as summarised in the following tables. 



Table 34: TDMA frame mapping on TP channel 



Frame 


DOWNLINK 


UPLINK 


FN 


Block BKN1 


Block BKN2 


Subslot SSN1 


Subslot SSN2 




TCH 


TCH 


1 to 17 


STCH + TCH 


STCH + TCH 




STCH + STCH 


STCH + STCH 


18 


SCH/F 


SCH/F 




SCH/HD 


SCH/HD 


SCH/HU 


SCH/HU 




BSCH 


SCH/HD 


CLCH 


SCH/HU 




SCH/HD 


BNCH 







Table 35: TDMA frame mapping on CP channel 



Frame 
FN 


DOWNLINK 


UPLINK 


Block BKN1 | Block BKN2 


Subslot SSN1 Subslot SSN2 


1 to 18 


SC 

SCH/HD 
SCH/HD 


H/F 

SCH/HD 
BNCH 


SC 

SCH/HU 
CLCH 


H/F 

SCH/HU 
SCH/HU 


18 


BSCH 


SCH/HD 
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Table 36: TDMA frame mapping on unallocated physical channel 



Frame 
FN 


DOWNLINK 


UPLINK 


Block BKN1 


Block BKN2 


Subslot SSN1 


Subslot SSN2 


1 to 18 


SCH/HD 
BSCH 


SCH/HD 
BNCH 


CLCH 





In all cases the AACH shall be mapped onto the broadcast block of each downlink slot. On the downlink 
the BLCH may replace the SCH/HD of the block BKN2. 

9.5.2 Mapping of BCCH and CLCH 

The BCCH and CLCH shall be mapped on the control frame of CP and TP channels. 



Table 37: Mapping of the BCCH onto the control frame 



Multiframe 


Frame 




Timeslot 






FN18 


TN1 


TN2 


TN3 


TN4 


(M/V)mod 4 = 1 


downlink BKN1 




BSCH 






downlink BKN2 








BNCH 




uplink SSN1 




CLCH 






(MA/)mod 4 = 2 


downlink BKN1 


BSCH 








downlink BKN2 






BNCH 






uplink SSN1 


CLCH 








(MA/)mod 4 = 3 


downlink BKN1 








BSCH 


downlink BKN2 




BNCH 








uplink SSN1 








CLCH 


(MA/)mod 4 = "0" 


downlink BKN1 






BSCH 




downlink BKN2 


BNCH 










uplink SSN1 






CLCH 





The mapping of the BCCH and CLCH on the control frame shall be a function of the time slot and 
multiframe numbers and shall be obtained from the following algorithms or from table 37. 



Down-link: 

BNCH mapped if: 

FA/= 18 and (MA/+ TA/)mod 4 = 1. (72) 
BSCH mapped if: 

FA/ = 18 and (MN + TA/)mod 4 = 3. (73) 
Up-link: 

CLCH mapped if: 

FN = 1 8 and (MN + 7A/)mod 4 = 3. (74) 
The BSCH shall always be transmitted on a synchronisation burst. 

In addition to this mapping the BS may map the CLCH onto the up-link subslot 1 and the BNCH on the 
downlink block 2 of a CP channel. The mapping shall be performed on a slot to slot basis. The mapping of 
the CLCH shall be indicated on the AACH. 

A MS may linearize its transmitter at any CLCH occurrence, even from another physical channel, provided 
this does not violate other mapping rules. The number of MS transmitter linearizations on one carrier is 
limited to once per multiframe period. 
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The BLCH may be mapped onto block 2 of the downlink slots, when a SCH/HD or a BSCH is mapped 
onto block 1 . The number of BLCH occurrences on one carrier shall not exceed one per 4 multiframe 
periods. 

At initial power-on of an RF carrier, the BS may linearize its transmitter using the BLCH. In this case the 
BLCH is mapped on a burst similar to the downlink linearization burst, but with an unspecified duration 
preceding the start burst. 

Slots of an unallocated physical channel may be filled up with the BCCH, the BSCH is mapped onto block 
1 and BNCH onto block 2. Whenever a BCCH is mapped on the down-link, a CLCH may also be mapped 
onto the up-link. 

9.5.3 Mapping of SCH 

On the up-link one SCH/F or two SCH/HU (one on each subslot) may be mapped, except if a CLCH is 
mapped on subslot 1 (formula 3) then only one SCH/HU may be mapped, onto subslot 2. On the 
down-link one SCH/F or two SCH/HD may be mapped on blocks 1 and 2 except on the control frame if a 
BNCH is mapped onto block 2, then only one SCH/HD shall be mapped onto block 1 . 

Whenever a normal downlink burst is transmitted on an UP channel and if no BCCH is transmitted then 
the SCH/HD shall be mapped onto blocks 1 and 2. The SCH/HD shall contain dummy messages (null 
SDU as described in clause 21). 

The BS shall indicate on the AACH the type of logical channel(s) to be used on the next up-link subslot 
(SCH/HU or CLCH) or slot (SCH/F). This indication shall only be valid within one frame and for one 
physical channel. 

In the case where several downlink TP channels are allocated to one single communication, the uplink 
and downlink SCH shall be mapped onto frame FN18 of the allocated physical channel showing the 
lowest timeslot number TN. 

In the case where several uplink TP channels are allocated to one single communication, the uplink and 
downlink SCH shall be mapped onto frame FN18 of the allocated physical channel showing the highest 
timeslot number TN. 

9.5.4 Mapping of TCH and STCH 

The TCH shall be mapped onto blocks 1 and 2 of the frames 1 to 17 of a TP channel. 

The STCH may be mapped onto any frame allowed for traffic. The STCH steals a part or all of the TCH 
bits within a burst. 

The presence of stolen traffic in one burst shall be indicated by the type of training sequence. 
In case of stealing, the STCH shall always steal first the first half slot of the burst. 

9.5.5 Mapping of AACH 

The AACH is mapped onto the broadcast block of each downlink slot. 
9.6 Monitoring pattern for transmitting MSs 

A particular monitoring pattern shall be referenced by its Monitoring Pattern Number (MPN). The 
monitoring patterns shall be numbered from 1 to 3. The BS shall assign 0 to 3 patterns to each up-link 
TCH during the call or transaction set-up. The transmitting MS shall monitor at least all frames belonging 
to the assigned monitoring pattern(s). In some cases, the BS may allocate no monitoring pattern, but, as a 
result, the MS may not be so easily reachable. 

For a given monitoring pattern, the frame sequence may be obtained with the following formula or by 
using table 38. 



(MN + MPN-1)mod 3 = (FN)mod 3. 



(75) 
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Table 38: Monitoring patterns for transmitting MSs 



Multiframe 


Monitoring Patterns 




MPN1 


MPN2 


MPN3 


(MN)mod 3 = 1 


FN1.4, 7, 10, 13, 16 


FN2.5.8, 11,14,17 


FN3, 6, 9,12,15,18 


(MN)mod 3 = 2 


FN2, 5, 8,11,14,17 


FN3.6.9, 12,1518 


FN1.4, 7,10,13,16 


(MN)mod 3 = 0 


FN3,6,9, 12, 15 18 


FN1.4, 7, 10,13,16 


FN2, 5, 8,11,14,17 



9.7 BS timesharing transmission 



9.7.1 Carrier sharing 

In carrier sharing mode one carrier frequency shall be shared among up to four cells, each cell being 
allocated at least one physical channel. The mapping of logical channels into physical channels shall 
follow the general mapping rules, except that on the downlink discontinuous bursts shall be used, (see 
also subclause 23.3.2.1 ). 

9.7.2 MCCH sharing 

In MCCH sharing mode, the MCCH shall be shared among several cells. The TDMA frames of the MCCH 
shall be divided into frames reserved to one BS (reserved frames) and frames shared by all cells 
(common frames). The BS shall transmit during the reserved frames and may transmit during the 
common frames. The transmission during the common frames should be managed by the network (see 
also subclause 23.3.2.2). 

The frames reserved for a BS shall be calculated from the TS_RESERVED_FRAMES parameter that 
indicates the number of reserved frames per two multiframes. This parameter may take one of the 
following values: 

1,2,3,4,6,9,12,18; 

and shall be broadcast on the BSCH. Up to 36 cells may share the same MCCH. The FN of the reserved 
frames may be obtained from the following formula or from table 39. 

the frame FN in the multiframe MN is reserved to the BS if: 

FN + 1 8 [(MN + 1 )mod 2] is a multiple of 36/TS_RESERVED_FRAMES. (76) 

For any value of TS_RESERVED_FRAMES, frame 18 of the even multiframes shall be reserved, in order 
to transmit the BCCH. The TDMA frame and multiframe numbering of all cells sharing one MCCH shall be 
offset in order to avoid collision of the transmitted bursts. 

The allocation of the common frames shall be sent on the BNCH. 

The mappings of logical channel into physical channel shall follow for the reserved and common frames 
the same rules as for continuous transmission, except that on the downlink the discontinuous bursts shall 
be used. 

9.8 Modes of control 

Two modes of control are defined: 

Normal Control Mode (NCM); and 

Minimum Control Mode (MCM). 
9.8.1 NCM 

The NCM is a mode of operation providing the TETRA services with full performance. In NCM a MCCH 
shall be assigned. 
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9.8.2 



MCM 



The MCM is a mode of operation providing the TETRA services with reduced performance. In MCM all 
physical channels may be TP channels. 

Table 39: Reserved frames in BS timing 




1 0 Radio subsystem link control 
10.1 Introduction 

This clause specifies the radio subsystem link control implementation in mobile and BSs for V+D. The 
following aspects of radio subsystem link control are addressed: 

RF power control; 

the basis for signal strength measurement. 



Page 91 

ETS 300 392-2: March 1996 



1 0.2 RF power control 

Adaptive RF power control shall be used by the MS. By minimising the transmit power levels, interference 
to co-channel and adjacent channel users is reduced and MS power consumption could be reduced. 
Adaptive RF power control shall not be used by the BS. 

10.3 Radio link measurements 

The radio link measurements include signal strength, signal quality and round-trip MS-BS path delay. 
10.3.1 Received signal strength 

The received signal strength shall be measured over the range from - 110 dBm to - 48 dBm with an 
absolute accuracy of ± 4 dB. The relative accuracy between two measurements on the same carrier or on 
different carriers shall be ± 3 dB. The parameters relative to signal strength shall be coded as in table 40. 



Table 40: Signal strength parameter definition 



Parameter value 


Signal strength measured at t 
from 


he antenna connector (dBm) 
to 


0 




-110 


1 


-110 


-109 


2 


-109 


-108 








62 


-49 


-48 


63 


-48 





1 0.3.1 .1 Sample duration for signal strength measurement 

To enable correct measurement of the received signal strength, the minimum Sample Duration (SD) shall 
be one of the following defined values: 

SD1 = 1 ms sample duration; 

SD2 = 4 ms sample duration. 

10.3.2 Signal quality 

The quality of the radio downlink shall be estimated from the success rate of decoding the AACH (see 
clause 23). 

1 0.3.3 Round-trip MS-BS path delay 

The round-trip MS-BS path delay may be used by the BS as a criterion to relinquish a radio uplink. The 
path delay of the MS is a representation of the distance of the MS to the serving BS. This distance may be 
used to prevent MS grossly exceeding the planned cell boundaries. This information may be sent by the 
BS to the MS when appropriate. The allowable distance may be restricted on a cell to cell basis by the 
network operator, as required. 

1 1 Call Control (CC) service description 

11.1 Introduction 

This clause describes the services offered by the CC sub-entity in the Circuit Mode Control Entity (CMCE). 
The CC Service Access Point (SAP) is used in conformance testing as a normative boundary in TETRA 
MSs and TETRA LSs. 
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11.2 Services offered 

The CC services shall be provided with a CC sub-entity at the service access point TNCC-SAP. In order to 
cater for concurrent services there may exist multiple instances of the TNCC-SAP running at the same 
time. 

At the TNCC-SAP one instance of the call control shall consist a set of the following calling user 
application and called user application services: 

basic call set-up (with attributes); 
call maintenance; 

Dual Tone Multiple Frequency (DTMF) encoding and sending; 
PTT requests/grants/information; 
call clearance; 

change of tele/bearer service within a call. 

11.3 CC service 

1 1 .3.1 CC primitives exchanged through the TNCC-SAP 

The flow of CC primitives shall be as illustrated in figure 13. 



T 



SIGNAL 

TNCC-ALERT indication, 
TNCC-COMPLETE indication, 
TNCC-COMPLETE request, 
TNCC-COMPLETE confirm, 
TNCC-DTMF request, 
TNCC-DTMF indication, 
TNCC-MODIFY indication, 
TNCC-MODIFY request, 
TNCC-NOTIFY indication, 
TNCC-PROCEED indication, 
TNCC-RELEASE indication, 
TNCC-RELEASE request, 
TNCC-RELEASE confirm, 
TNCC-SETUP indication, 
TNCC-SETUP response, 
TNCC-SETUP request, 
TNCC-SETUP confirm, 
TNCC-TX indication, 
TNCC-TX request, 
TNCC-TX confirm, 



TNCC-ALERT indication, 
TNCC-COMPLETE indication, 
TNCC-DTMF indication, 
TNCC-MODIFY indication, 
TNCC-NOTIFY indication, 
TNCC-PROCEED indication, 
TNCC-RELEASE confirm, 
TNCC-RELEASE indication, 
TNCC-SETUP confirm, 
TNCC-SETUP indication, 
TNCC-TX indication, 
TNCC-TX confirm, 




TNCC-COMPLETE request, 
TNCC-COMPLETE confirm, 
TNCC-DTMF request, 
TNCC-MODIFY request, 
TNCC-RELEASE request, 
TNCC-SETUP request, 
TNCC-SETUP response, 
TNCC-TX request, 



CC SERVICE 
MS/LS 



Figure 13: CC services provided at TNCC-SAP MS/LS-side 
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1 1 .3.2 Service primitives at the TNCC-SAP 

Each TNCC-SAP shall be characterised by a SAP and the set of service primitives available for each SAP 
shall be as specified in this subclause. 

TNCC-ALERT indication: the primitive shall be used in the call set-up phase towards the calling user 
application when on/off hook signalling is employed. 

TNCC-COMPLETE request/indication/confirm: the primitive shall be used as a termination of the call 
set-up phase at the called user application. 

TNCC-DTMF request/indication: the primitives may be used during a circuit mode call to exchange 
DTMF information between user applications. 

NOTE: One of the users applications could be a gateway. 

TNCC-MODIFY request/indication: the primitives may be used during call active phase as an indication 
that an existing tele- or bearer service has been modified. 

TNCC-NOTIFY indication: the primitives may be used during call set-up and call active phases to notify 
the user application about the status of the call. 

TNCC-PROCEED indication: the primitive may be used during call set-up phase to indicate progress of 
the call set-up. 

TNCC-RELEASE request/indication/confirm: the primitives shall be used to initiate the call release 
phase. Further it shall be used to indicate the termination of the call release phase. The primitives may 
also be used during the call set-up phase to request or indicate rejection of a call. 

TNCC-SETUP request/indication/response/confirm: the primitives shall be used to initiate the call set- 
up phase and shall also be used to indicate the termination of the call set-up phase. 

TNCC-TX request/indication/confirm: the primitives shall be used during call active phase to request 
and indicate change in the transmission permission. 

1 1 .3.3 Primitive description 

The information contained in the primitive description tables which follow corresponds to the following key: 
KEY: M: Mandatory; C: Conditional; O: Optional; -: Not used. 
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1 1 .3.3.1 TNCC-ALERT primitive 

TNCC-ALERT indication shall be used to indicate to the calling user application, that the call has been 
received, and alerting at the called user application has been initiated. The called user application is using 
on/off hook signalling and the primitive indicates that the called user application is alerting. 

The parameters are defined in table 41 . 



Table 41: Parameters for the primitive TNCC-ALERT 



Parameter 


Indication 


Basic service information (offered): 




Circuit mode service 


O 


Communication type 


O 


Data call capacity 


C (note) 


Data service 


C (note) 


Encryption flag 


O 


Speech service 


C (note) 


Call status 


0 


Simptex/duplex 


M 


NOTE: Depending on the value of circuit mode service. 



1 1 .3.3.2 TNCC-COMPLETE primitive 

TNCC-COMPLETE request shall be used by the called user application to complete call set-up. 

TNCC-COMPLETE indication shall be used as an indication to the called user application that the call 
set-up has been completed. The called user application shall also be informed whether the SwMI has 
granted transmission permission to the calling user application or whether the right to transmit has been 
handed over to the another user application. 

TNCC-COMPLETE confirm shall be used to confirm to the called user application that the call set-up has 
been completed. 

The parameters are defined in table 42. 



Table 42: Parameters for the primitive TNCC-COMPLETE 



Parameter 


Request 


Indication 


Confirm 


Call time-out 




M 


M 


Transmission request permission 




M 


M 


Transmission status 




M 


M 



1 1 .3.3.3 TNCC-DTMF primitive 

TNCC-DTMF request shall be used as a request from the user application to send a number of DTMF 
digits to another user application. 

TNCC-DTMF indication shall be used as an indication to the user application that a number of DTMF 
digits has arrived from another user application. 

The parameters are defined in table 43. 



Table 43: Parameters for the primitive TNCC-DTMF 



Parameter 


Request 


Indication 


Access priority 


O 




DTMF diqits 


M 


M 


Traffic stealinq 


O 
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1 1 .3.3.4 TNCC-MODIFY primitive 

TNCC-MODIFY request shall be used as a request from the user application to the SwMI to change the 
call attributes and/or the simplex/duplex selection. 

NOTE: If a change in call attribute is requested, it cannot change from point-to-multipoint-to- 
point-to-point. 

TNCC-MODIFY indication shall be used as an indication to a user application that the call attribute has 
changed from one tele/bearer service to another tele/bearer service. The primitive shall also be used for 
indicating a change in the call timer or a change in the simplex/duplex operation. 

The parameters are defined in table 44. 



Table 44: Parameters for the primitive TNCC-MODIFY 



Parameter 


Request 


Indication 


Access priority 


0 




Basic service information (new): 






Circuit mode service 


0 


0 


Communication type 


0 


O 


Data call capacity 


C (note) 


C (note) 


Data service 


C (note) 


C (note) 


Encryption flag 


O 


0 


Speech service 


C (note) 


C (note) 


Call time-out 




0 


Simplex/duplex 


O 


O 


Traffic stealing 


O 




NOTE: Depending on the value of circuit mode service. 



1 1 .3.3.5 TNCC-NOTIFY primitive 

TNCC-NOTIFY indication shall provide information from the SwMI to the user application about a circuit 
mode call. 

The parameters are defined in table 45. 



Table 45: Parameters for the primitive TNCC-NOTIFY 



Parameter 


Indication 


Call status 


0 


Call time-out in set-up phase 


O 


Poll result identifier 


O 


Poll response percentage 


C (note) 


Poll response number 


C (note) 


Poll response addresses 


C (note) 


Poll request 


0 


NOTE: Depending on the value of poll result identifier. 



11.3.3.6 TNCC-PROCEED primitive 

TNCC-PROCEED indication shall be used as an indication to the user application that call establishment 
has been initiated in the SwMI. The indication may also contain information about changes in call 
attributes, changes in the hook method or the simplex/duplex operation. 

The parameters are defined in table 46. 
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Table 46: Parameters for the primitive TNCC-PROCEED 



Parameter 


Indication 


Basic service information (offered): 




Circuit mode service 


0 


Communication type 


0 


Data call capacity 


C (note) 


Data service 


C (note) 


Encryption flag 


0 


Speech service 


C (note) 


Call status 


0 


Hook method 


0 


Simplex/duplex 


0 


NOTE: Depending on the value of circuit mode service 



1 1 .3.3.7 TNCC-RELEASE primitive 

TNCC-RELEASE request shall be used by the user application to either leave a continuing call or request 
disconnection of the call. If he wants to disconnect the call the SwMI is requested to release the 
connection. The SwMI is also requested to release the call identifier and all connections associated with it. 

TNCC-RELEASE indication shall be used as an indication to the user application, that the SwMI has 
released the call identifier and the corresponding connection. 

TNCC-RELEASE confirm shall be used to indicate to the initiator of the call release, that the SwMI has 
released the call identifier and the connection. 

The parameters are defined in table 47. 



Table 47: Parameters for the primitive TNCC-RELEASE 



Parameter 


Request 


Indication 


Confirm 


Disconnect cause 


M 


M 


M 


Disconnect status 






M 


Disconnect type 


M 







1 1 .3.3.8 TNCC-SETUP primitive 

TNCC-SETUP request shall be used to initiate the call establishment of a circuit switched call by a calling 
user application. 

TNCC-SETUP indication shall be used as an indication to a called user application that a call 
establishment has been initiated and a circuit switched call is in progress or has been established. 

TNCC-SETUP response shall be used by the called user application to indicate that the call has been 
accepted and call set-up can now proceed towards the call active phase. The user application may 
change the attributes of the call and the simplex/duplex operation may be changed. 

TNCC-SETUP confirm shall be used as a confirmation to the calling user application that the call set-up 
phase has now been terminated by the SwMI and an end-to-end connection has been set-up. The call 
shall now be considered as being in its active phase. 
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The parameters are defined in table 48. 



Table 48: Parameters for the primitive TNCC-SETUP 



Parameter 


Request 


Indication 


Response 


Confirm 


Access priority 


0 




O 




Area selection 


0 


- 


- 


- 


Basic service information; 










Circuit mode service 


M 


M 


O 


M 


Communication type 


M 


M 


0 


M 


Data call capacity 


C (note 3) 


C (note 3) 


C (note 3) 


C (note 3) 


Data service 


C (note 3) 


C (note 3) 


C (note 3) 


C (note 3) 


Encryption flag 


M 


M 


O 


M 


Speech service 


C (note 3) 


C (note 3) 


C (note 3) 


C (note 3) 


Basic service information (minimum 
acceptable): 










Circuit mode service 


M 


- 


- 


- 


Communication type 


M 








Data call capacity 


C (note 3) 


- 


- 


- 


Data service 


C (note 3) 


- 


- 


- 


Encryption flag 


M 


- 


- 


- 


Speech service 


C (note 3) 


- 


- 


- 


Call priority 


M 


M 


- 


0 


Call ownership 


- 


- 


- 


M 


Call amalgamation 


- 


- 


- 


M 


Call time-out 


- 


M 


- 


M 


Called party type identifier 


M 


M 


- 


- 


Called party SSI 


C 

(notes 1 ,2) 


C(note 1) 


- 


- 


Called party extension 


C(note1) 


C(note1) 


- 


- 


Called party SNA 


C(note1) 


- 


- 


- 


Calling party type identifier 




0 






Calling party SSI 




C(note1) 






Calling party extension 




C(note1) 






External subscriber number 


0 


0 






Hook method selection 


M 


M 


M 


M 


Request to transmit/send data 


M 




M 


0 


Simplex/duplex selection 


M 


M 


0 


0 


Traffic stealing 


0 




0 




Transmission request permission 




M 




M 


Transmission status 




M 




M 


NOTE 1 : Depending on the value of called/calling party type identifier. 

NOTE 2: The application should ensure that individual calls (basic service) use called party ISSI, and 

group calls use GSSI. 
NOTE 3: Depending on the value of circuit mode service. 



1 1 .3.3.9 TNCC-TX primitive 

TNCC-TX request shall be used as a request from the user application that it wants to transmit or that it 
has ceased its transmission. In the request for transmission the requested priority and the encryption 
mode shall be indicated. 



TNCC-TX indication shall be used as an indication to the user application concerning the transmit status 
of the call. The primitive shall also be used to inform the user application about whether another user has 
been granted transmission or ceased its transmission. The encryption state of the actual transmission is 
indicated in the encryption control parameter. 

TNCC-TX confirm shall be used as a confirmation to the user application that the request to transmit has 
been granted. The encryption state of the actual transmission is indicated in the encryption control 
parameter. 
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The parameters are defined in table 49. 



Table 49: Parameters for the primitive TNCC-TX 



Parameter 


Request 


Indication 


Confirm 


Access priority 


0 


- 


- 


Encryption flag 


M 


M 


M 


Calling party type identifier 




0 




Calling party SSI 




C (note) 




Calling party extension 




C (note) 




Speech service 


M 


M 


M 


Traffic stealing 


0 






Transmission condition 


M 






Transmit request permission 




M 


M 


Transmission status 


M 


M 


M 


Tx demand priority 


M 






NOTE: Depending on the value of calling party type identifier. 



1 1 .3.4 Parameter description 

Parameters shall be part of the primitives described in subclause 1 1 .3.3. and if applied the parameters 
shall contain the values specified in this subclause. These values are selected to correspond to element 
values used in the air interface protocol. 

Access priority = 

0 low priority; 

1 high priority; 

2 emergency priority. 

Area selection = 

0 area not defined; 

1 area 1 ; 
etc. etc.; 

14 area 14; 

1 5 all areas in this system. 

Basic service information (a set of parameters) = 

circuit mode service; 
communication type; 
data service; 

data call capacity (data service only); 
encryption flag; 
speech service. 

Call amalgamation = 

0 call not amalgamated; 

1 call amalgamated. 

Call ownership = 

0 a call owner; 

1 not a call owner. 
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Call status = 

0 call status unknown; 

1 call is progressing; 

2 call is queued; 

3 requested subscriber is paged; 

4 requested subscriber is alerting; 

5 hang timer has expired. 

Call time-out = 

0 call time-out not defined; 

1 call time-out value-1; 

2 call time-out value-2; 

1 5 call time-out value-1 5. 
Refer to subclause 14.2.15 for the time-out values. 
Call time-out in set-up phase = 

0 call time-out not defined; 

1 call time-out value-1; 

2 call time-out value-2; 
etc. etc.; 

7 call time-out value-7. 

Refer to subclause 1 4.2.16 for the time-out values. 
Called party extension = 

country code and network code part of TSI. 
Called party SNA = 

Short Number Address (SNA). 
Called party SSI = 

Short Subscriber Identity (SSI). 
Called party type identifier = 

0 SNA; 

1 SSI; 

2 TETRA subscriber identity (TSI). 
Calling party extension = 

Mobile Country Code (MCC) + Mobile Network Code (MNC). 

Calling party SSI = 

Individual Short Subscriber Identity (ISSI); or 
Group Short Subscriber Identity (GSSI). 

Calling party type identifier = 

0 SSI; 

1 TSI. 
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Call priority = 

0 priority not defined; 

1 lowest priority; 
etc. etc.; 

1 1 highest non-pre-emptive priority; 

1 2 lowest pre-emptive priority; 
etc. etc.; 

1 4 second highest pre-emptive priority; 

1 5 highest pre-emptive priority, generates emergency call. 

Circuit mode service = 



0 data service; 

1 speech service. 



Communication type = 



0 point-to-point; 

1 point-to-multipoint; 

2 point-to-multipoint acknowledged; 

3 broadcast. 

Data service (service per one time slot) = 



0 unprotected: 7,2 kbit/s, no interleaving; 

1 low protection: 4,8 kbit/s, short interleaving depth = 1 ; 

2 low protection: 4,8 kbit/s, medium interleaving depth = 4; 

3 low protection: 4,8 kbit/s, long interleaving depth = 8; 

4 high protection: 2,4 kbit/s, short interleaving depth = 1 ; 

5 high protection: 2,4 kbit/s, medium interleaving depth = 4; 

6 high protection: 2,4 kbit/s, long interleaving depth = 8. 

NOTE: The increase in interleaving depth gives a better error protection, but also generates a 
longer transmission delay. 



Data call capacity = 

0 one time slot; 

1 two time slots; 

2 three time slots; 

3 four time slots. 



Disconnect cause = 



0 


cause not defined or unknown; 


1 


user requested disconnect; 


2 


called party busy; 


3 


called party not reachable; 


4 


called party does not support encryption; 


5 


congestion in infrastructure; 


6 


not allowed traffic case; 


7 


incompatible traffic case; 


8 


requested service not available; 


9 


pre-emptive use of resource; 


10 


invalid call identifier; 


11 


call rejected by the called party; 


12 


no idle CC entity; 


13 


expiry of timer; 


14 


SwMI requested disconnection; 


15 


acknowledged service not completed. 



Page 101 

ETS 300 392-2: March 1996 

Disconnect status = 

0 disconnection successful; 

1 disconnection unsuccessful, the user is released from the call; 

2 disconnection unsuccessful, not the call owner, the user is released from the call; 

3 the user is released from the call. 

Disconnect type = 

0 disconnect call; 

1 leave call without disconnection. 

DTMF digits = 

Up to 255 DTMF digits. Each digit shall be one of the following: 



0 


digit 0; 


etc. 


etc.; 


9 


digit 9; 


10 


digit*; 


11 


digit #; 


12 


digit A;; 


13 


digit B; 


14 


digit C; 


15 


digit D. 



Encryption flag = 

0 clear end-to-end transmission; 

1 encrypted end-to-end transmission. 

External subscriber number digits = 

Up to 24 DTMF digits. Each digit shall be one of the following: 



0 


digit 0; 


etc. 


etc.; 


9 


digit 9; 


10 


digit *; 


11 


digit #; 


12 


digit A; 


13 


digit B; 


14 


digit C; 


15 


digit D. 



Hook method selection = 

0 no hook signalling (direct through-connect); 

1 hook on/hook off signalling (individual call); and call acceptance signalling (group call). 
Poll request = 

0 no poll answer requested; 

1 poll answer requested. 

Poll response addresses = 



TSI addresses 1-N. 
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Poll result identifier = 

0 poll result not known; 

1 the percentage of responding group members; 

2 the number of responding group members; 

3 the addresses of the responding group members. 

Poll response number = 

0 no poll response; 

1 1 poll response; 
etc. etc.; 

63 or more poll responses. 
Poll response percentage = 

0 0 %; 

1 1 %; 
etc. etc.; 
100 100%. 

Request to transmit/send data = 

0 request to transmit/send data; 

1 request that other MS/LS may transmit/send data. 

Simplex/duplex selection = 

0 simplex operation; 

1 duplex operation. 

Speech service = 

0 TETRA encoded speech; 

1 7,2 kbit/s unprotected data. 

NOTE: This service should carry a non-TETRA encoded speech and channel coding. 
Traffic stealing = 

0 don't steal traffic; 

1 steal traffic. 

Transmission condition = 

0 request to transmit; 

1 transmission ceased. 

Transmission request permission = 

0 allowed to request for transmission; 

1 not allowed to request for transmission. 

Transmission status = 

0 transmission ceased; 

1 transmission granted; 

2 transmission not granted; 

3 transmission request queued; 

4 transmission granted to another user; 

5 transmission interrupt; 

6 transmission wait; 

7 transmission request failed. 



Page 103 

ETS 300 392-2: March 1996 



Tx demand priority = 

0 no priority level; 

1 low priority level; 

2 high priority level; 

3 pre-emptive priority level; 

4 emergency pre-emptive priority level. 

11.4 States for CC SAP 

The state transitions visible at the TNCC-SAP shall be as shown in figure 14: 



TNCC-RELEASE request 



ANY STATE 



CALL 



TNCC-RELEASE request^^-^ D | SC0NNECT 



V\TNCC-RELEASE request 



After initial Start Up 

TNCC PROCEED indication 
TNCC-NOTIFY indication 
TNCC-MODIFY indication 
TNCC- ALERT indication^ 

MO CALL \ TNCC-SETUP requei 
SETUP 



\ /TNCC-RELEASE confirm 



TNCC-RELEASE 



TNCC-SETUP confirrrNN 




TNCC-RELEASE indication 



MT_CALL 
SETUP 



/TNCC-SETUP response 
TNCC-RELEASE request 
TNCC-NOTIFY indication 
TNCC-COM PLETE request 
TNCC-MODIFY request 
TNCC-MODIFY indication 



CALL 
ACTIVE 



TNCC-COM PLETE indication 
TNCC-COM PLETE confirm 
TNCC-SETUP indication 
TNCC-SETUP response 



TNCC-DTMF request/indication 
TNCC-MODIFY request/indication 
TNCC-NOTIFY request/indication 
TNCC-TX request/indication/confirm V 



Figure 14: State transition diagram for one instance at the CC SAP 
1 2 Supplementary Services (SS) service description 
12.1 Introduction 

This clause describes the services offered by the CMCE at the SS SAP of the TETRA V+D layer 3 service 
boundary. This SAP with the CC SAP is used in supplementary service conformance testing as a 
normative boundary in TETRA MSs and in TETRA LSs. 
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1 2.2 Services offered 

The SS services shall be provided at the TNSS-SAP. 

The SS may consist of the following services: 

invocation of an SS; 
activation/deactivation of an SS; 
definition of an SS; 
cancellation of an SS; 
interrogation of an SS; 

registration of a user to a supplementary sen/ice; 
reception of supplementary service messages. 

12.3 SS service 

1 2.3.1 Primitives exchanged through TNSS-SAP 

The flow of SS primitives shall be as illustrated in figure 1 5. 



SIGNAL 

TNSS-ERROR indication, 
TNSS-INFO confirm, 
TNSS-INFO indication, 
TNSS-INFO request, 
TNSS-INFO response, 
TNSS-SERVICE confirm 
TNSS-SERVICE indication, 
TNSS-SERVICE request, 
TNSS-SERVICE response 



TNSS-ERROR indication, 
TNSS-INFO indication, 
TNSS-INFO confirm, 
TNSS-SERVICE indication, 
TNSS-SERVICE confirm 



TNSS-SAP 



TNSS-INFO request, 
TNSS-INFO response, 
TNSS-SERVICE request, 
TNSS-SERVICE response 



SS SERVICE 
MS 



12.3.2 



Figure 15: SS services provided at TNSS-SAP/MS-side 
Service primitives 



The following 3 generic services shall be provided at the TNSS-SAP as defined below. The use of the 
services shall depend upon the SS: 

a) TNSS-SERVICE; 

b) TNSS-INFO; 

c) TNSS-ERROR. 

The TNSS-SERVICE shall enable an invoking entity to request and to be informed about, an operation to 
be performed by the performing entity. 



The TNSS-INFO shall enable an entity to be informed of ongoing transactions. 
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The TNSS-ERROR shall enable a performing entity to return the negative reply of a unsuccessfully 
performed operation to the invoking entity. 

1 2.3.3 Service primitives at the TNSS-SAP 

1 2.3.3.1 TNSS-ERROR indication 

The TNSS-ERROR indication shall be sent to the user application in the case of an unsuccessfully 
performed or rejected operation, in response to a previous TNSS-SERVICE request. The return error may 
be SS specific. 

1 2.3.3.2 TNSS-SERVICE indication 

The TNSS-SERVICE indication shall be sent to the user application which may cause the invocation of an 
operation to be performed by the user application. This may be simply the transfer of information as a 
result of a SS invocation, e.g. call waiting notification. 

1 2.3.3.3 TNSS-SERVICE request 

This request shall be sent by the user application, to cause the invocation of an operation to be performed 
by the SS entity. This may be the invocation/activation etc. of a SS. 

1 2.3.3.4 TNSS-SERVICE confirm 

This confirmation shall be sent to the user application, to reply to a previous TNSS-SERVICE request. 

1 2.3.3.5 TNSS-SERVICE response 

This response should be sent by the user application, if required, to respond to a previous 
TNSS-SERVICE indication. 

1 2.3.3.6 TNSS-INFO confirm 

This primitive shall contain information from the SS entity to the user application concerning a completing 
transaction. 

1 2.3.3.7 TNSS-INFO indication 

This primitive shall contain information sent to the user application concerning an ongoing transaction. 

1 2.3.3.8 TNSS-INFO request 

This primitive shall be sent by the user application to request information concerning an ongoing 
transaction. 

12.3.3.9 TNSS-INFO response 

This primitive should contain information sent by the user application concerning an ongoing transaction in 
response to a TNSS-INFO indication. 

12.3.4 Primitive description 

The information contained in the primitive description tables which follow corresponds to the following key: 
KEY: M: Mandatory; C: Conditional; O: Optional; -: Not used. 
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1 2.3,4.1 TNSS-ERROR primitive 

The parameters shall be defined as follows: 



Table 50: Parameters for the primitive TNSS-ERROR 



Parameter 


Indication 


Invoke-ID 


M 


Error value 


M 


Error parameter 


0 



The Invoke-ID shall be, in the call related SS, the call instance number (see subclause 11.3.4). 
1 2.3.4.2 TNSS-INFO primitive 

The parameters are defined in table 51 . 



Table 51 : Parameters for the primitive TNSS-INFO 



Parameter 


Request 


Indication 


Response 


Confirm 


Invoke-ID 


M 


M 


M 


M 


SS ID 


M 


M 


M 


M 


Operation type 


M 


M 


M 


0 


Operation argument 


0 


0 


O 


M 



The Invoke-ID shall be, in the call related SS, the call instance number (see subclause 11 .3.4). 
1 2.3.4.3 TNSS-SERVICE primitive 

The parameters are defined in table 52. 



Table 52: Parameters for the primitive TNSS-SERVICE 



Parameter 


Request 


Indication 


Response 


Confirm 


Invoke-ID 


M 


M 


M 


M 


SS ID 


M 


M 


M 


M 


Operation type 


M 


M 


M 


M 


Operation argument 


O 


0 


O 


0 



The Invoke-ID shall be, in the call related SS, the call instance number (see subclause 11 .3.4). 
1 2.3.5 Parameter description 
Error value: 

this parameter shall identify the error that occurred during the execution of the operation. 
Error parameter: 

this parameter shall provide additional information about the error. The reasons for errors shall be 
either a) reject reason or b) operational problem: 

a) re j ec t reason: rejection of a SERVICE/INFO request/response primitive, with the following 
values as examples: 

invalid invoke-ID; 

shall signify that the invoke-ID parameter violates the assignment rules; 
unrecognised operation; 
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shall signify that the operation is not one of those agreed between entities; 

incorrect operation type; 

shall signify that the operation type supplied is not correct e.g. the SS cannot be 
invoked because the SS can only be activated by the user; 

incorrect operation argument; 

shall signify that the operation argument supplied is not correct e.g. the 
identification of the diverted-to user is not allowed; 

resource limitation; 

shall signify that the performing entity is not able to perform the invoked 
operation due to resource limitation; 

unrecognised invoke-ID; 

shall signify that there is no operation in progress with an invoke-ID equal to the 
specified invoke-ID; 

b) operational problem: operational problem with a SERVICE/INFO request/response primitive, 
with the following values as examples: 

duplication operation type; 

shall signify that the user has previously requested the same service which is 
presently in the process of being performed; 

supplementary service interactions; 

shall signify that the request can not be performed because of supplementary 
service interactions at calling/called user; 

system interactions; 

shall signify that the request can not be performed because of interactions within 
the system e.g. lack of system resources; 

Invoke-ID: 

this parameter shall identify the request/response of the SERVICE/INFO service and shall be used 
to correlate this request/response with the corresponding replies (TNSS-ERROR, TNSS-SERVICE 
and TNSS-INFO services); 

this parameter shall distinguish several requests/responses of the service the requester may have 
in progress. The requester may begin to re-use invoke-ID values whenever it chooses, subject to 
the constraint that it shall not reuse an invoke-ID value that was previously assigned to a 
request/response of the service for which it expects, but has not yet received, an indication/confirm; 

Supplementary service ID: 

this parameter shall be the identifier of the SS type e.g. SS-CFU; 

Operation type: 

this parameter shall identify the operation to be performed e.g. activation, invocation etc.; 
Operation argument: 

this parameter shall give the details of the supplementary service e.g. identification of the diverted 
to subscriber. 
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13 Short Data Service (SDS) service description 

13.1 Introduction 

This clause describes the services offered by the short data service sub-entity in the CMCE at the SDS 
SAP of the TETRA V+D layer 3 service boundary. The SDS SAP is used in conformance testing as a 
normative boundary in TETRA MSs and in TETRA LSs. 

1 3.2 Services offered 

The SDS shall be provided by a single SDS functional entity at the TNSDS-SAP. 

The short data functional entity shall consist of the following mobile originated and mobile terminated 
services: 

a) user defined short message reception and transmission; 

individual message; 
group message; 

b) pre-defined short message reception and transmission; 

individual message; 
group message. 

13.3 SDS 

1 3.3.1 SDS primitives exchanged through the TNSDS-SAP 

TNSDS-STATUS request/indication: The primitives shall be used to send or receive a pre-coded 
message defined by either this ETS or by the network operator. 

TNSDS-REPORT indication: The primitive shall be used to indicate whether a TNSDS-UNITDATA 
request or a TNSDS-STATUS request has been either transmitted successfully or the transmission failure 
reason. 

TNSDS-UNITDATA request/indication: The primitives shall be used to send or receive a user defined 
message. 

The flow of short data service primitives shall be as illustrated in figure 16. 



SIGNAL 

TNSDS-STATUS request, 
TNSDS-STATUS indication, 
TNSDS-REPORT indication, 
TNSDS-UNITDATA request 
TNSDS-UNITDATA indication 



TNSDS-STATUS indication, 
TNSDS-REPORT indication, 
TNSDS-UNITDATA indication 



TNSDS-SAP 



O 



TNSDS-STATUS request, 
TNSDS-UNITDATA request 



SDS SERVICE 
MS 



Figure 16: SDS provided at TNSDS-SAP (MS/LS-side) 
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1 3.3.2 Service primitives at the TNSDS-SAP 

The information contained in the primitive description tables which follow corresponds to the following key: 
KEY: M: Mandatory; C: Conditional; O: Optional; -: Not used. 
1 3.3.2.1 TNSDS-STATUS primitive 

TNSDS-STATUS request shall be used by the user application to send a pre-defined message to another 
user or users given in the address parameter. 

NOTE: The status message is selected from a set of pre-coded messages and only the status 
number is given as a parameter. 

TNSDS-STATUS indication shall indicate to the user application that a pre-coded status message from 
another user application has been received. 

The parameters are defined in table 53. 



Table 53: Parameters for the TNSDS-STATUS primitive 



Parameter 


Request 


Indication 


Access priority 


O 




Traffic stealing 


O 




Area selection 


o 




Called party type identifier 


M 


M 


Called party SNA 


C(note1) 




Called party SSI 


C(note1) 


C(note 1) 


Called party extension 


C(note1) 


C(note1) 


External subscriber number 


0 




Calling party type identifier 




M 


Calling party SSI 




C (note 2) 


Calling party extension 




C (note 2) 


Status number 


M 


M 


NOTE 1 : Depending on the value of called party type identifier. 
NOTE 2: Depending on the value of calling party type identifier. 



1 3.3.2.2 TNSDS-REPORT primitive 

TNSDS-REPORT indication shall be used as an indication to the user application that the PDU belonging 
to a request, i.e. the TNSDS-UNITDATA request or the TNSDS-STATUS request, has been either 
transmitted successfully or lost. 

The parameters are defined in table 54. 



Table 54: Parameters for the TNSDS-REPORT primitive 



Parameter 


Indication 


Transfer result 


M 



1 3.3.2.3 TNSDS-UNITDATA primitive 

TNSDS-UNITDATA request shall be used by the user application to send a user defined message to 
another user application or applications given in the address parameter. 

TNSDS-UNITDATA indication shall be used as an indication to the user that a user application defined 
message from another user application has been received. The message may either be a user defined 
individual message or a user defined group message. 
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The parameters are defined in table 55. 



Table 55: Parameters for the TNSDS-UNITDATA primitive 



Parameter 


Request 


Indication 


Access priority 


0 


- 


Traffic stealing 


0 


- 


Area selection 


0 


- 


Called party type identifier 


M 


M 


Called party SNA 


C (notel) 


- 


Called party SSI 


C(note1) 


C(note 1) 


Called party extension 


C (note 1) 


C(note 1) 


External subscriber number 


0 




Calling party type identifier 




M 


Calling party SSI 




C (note 2) 


Calling party extension 




C (note 2) 


Short data type identifier 


M 


M 


User defined data-1 


C (note 3) 


C (note 3) 


User defined data-2 


C (note 3) 


C (note 3) 


User defined data-3 


C (note 3) 


C (note 3) 


User defined data-4 


C (note 3) 


C (note 3) 


NOTE 1 : Depending on the value of called party type identifier. 
NOTE 2: Depending on the value of calling party type identifier. 
NOTE 3: Depending on the value of short data type identifier. 



1 3.3.3 Parameter description 

Parameters shall be part of the primitives at the TNSDS SAP. When applied the parameters shall contain 
the values specified in this clause. 

Access priority = 

0 low priority; 

1 high priority; 

2 emergency priority. 

Area Selection = 

0 area not defined; 

1 area 1 ; 
etc. etc.; 

14 area 14; 

15 all areas in this system. 
Called party extension = 

MCC + MNC. 
Called party short number address = 

SNA. 

Called party SSI= 

ISSI; 
GSSI. 

Called party type identifier = 



0 SNA; 

1 SSI; 

2 TSI. 



Page 111 

ETS 300 392-2: March 1996 



Calling party extension = 

MCC + MNC. 

Calling party SSI = 

ISSI; or 
GSSI. 

Calling party type identifier = 

0 SNA; 

1 SSI; 

2 TSL 

External Subscriber Number = 

Up to 24 DTMF digits. Each digit shall be one of the following: 



0 


digit 0; 


etc. 


etc.; 


9 


digit 9; 


10 


digit *; 


11 


digit #; 


12 


digit A; 


13 


digit B; 


14 


digit C; 


15 


digit D. 



Status number = 

0 emergency call; 

1 to 32 767 reserved; 

32 768 to 65 535 available for TETRA network specific definition. 

Short data type identifier = 

0 user defined data- 1; 

1 user defined data-2; 

2 user defined data-3; 

3 user defined data-4. 

Traffic stealing = 

0 do not steal traffic; 

1 steal traffic. 

Transfer result = 

success; 
failure. 

User defined data 1 = 

1 6 bit user defined data 1 . 

User defined data 2 = 



32 bit user defined data. 
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User defined data 3 = 

64 bit user defined data. 
User defined data-4 = 

user defined data bits, maximum length 2 047 bits. 

1 3.3.4 State description 

13.3.4.1 NULL state 

No short data message shall be in progress. 

1 3.3.4.2 SHORT DATA INITIATED state 

Short data message sending in progress state. Waiting for the completion of a message transfer. 

1 3.3.5 Service state diagram for the TNSDS-SAP 

TN SDS-U N ITDATA indication 



14 CMCE protocol 
14.1 Introduction 

This clause defines the layer 3.2 CMCE air interface protocol for the MS and the LS. There shall be a 
peer-to-peer relationship between the layers on the terminal side and the SwMI side. The protocol for the 
SwMI side is however outside the scope of this ETS. The CMCE protocol is the network layer protocol that 
shall be used to provide services to an end user application in the area of CC services, of SDS and of 
supplementary services. 

This clause specifies: 

the functional requirements for implementations claiming conformance to this ETS; 

procedures for specific transmission of: 

control information for circuit mode services; 

call unrelated short data messages; 

control information for call related/call unrelated supplementary service messages; 

the encoding of the Protocol Data Units (PDUs) used for the transmission of data and control 
information; 

procedures for the correct interpretation of protocol control information. 




TNSDS-UN ITDATA request 
TNSDS-STATUS request 



Figure 17: Service state diagram for the mobile terminated short data message 



Page 113 
ETS 300 392-2: March 1996 



1 4.2 Overview of CMCE 



Figure 18 shows the position of the CMCE protocols in both the MS/LS and in the BS protocol stack. This 
ETS does not define a BS protocol architecture or user application SAPs for the CMCE within the SwMI. 

User applications 



TNCC-SAP 



TNSS-SAP 



TNSDS-SAP 



CMCE.MS 



LCMC-SAP 



CMCE.BS 



LCMC-SAP 



MLE 



CMCE-MS 
CMCE-BS 
LCMC-SAP 
MLE 

TNCC-SAP 
TNSDS-SAP 
TNSS-SAP 



Circuit Mode Control Entity, Mobile Station 

Circuit Mode Control Entity, Base Station 

Mobile Link Entity - Circuit Mode Control Service Access Point 

Mobile Link Entity 

TETRA Network - Call Control Service Access Point 
TETRA Network - Short Data Service Service Access Point 
TETRA Network - Supplementary Service Service Access Point 



14.2.1 



Figure 18: System view 
Communication routes of the CMCE model 



The CMCE model defines routes used for information exchange between the sub-entities as shown in 
figure 19. 

The external routes are routes between a sub-entity of the CMCE and an entity in another layer. Each 
external route shall be mapped onto a SAP. 

There are 4 external routes. 

The ra route shall correspond to the TNCC-SAP. The primitives exchanged on that route are described in 
clause 1 1 . 

The rb route shall correspond to the TNSS-SAP. The primitives exchanged on that route are described in 
clause 12. 

The re route shall correspond to the TNSDS-SAP. The primitives exchanged on that route are described 
in clause 1 3. 

The ri route shall correspond to the LCMC-SAP. The primitives exchanged on that route are described in 
clause 17. 

The internal routes are routes between sub-entities of the CMCE. 
There are 5 internal routes: 

the rd route shall be a route between the CC sub-entity and the PC sub-entity; 

the re route shall be a route between the SS sub-entity and the PC sub-entity; 

the rg route shall be a route between the SS sub-entity and the CC sub-entity; 

the rf route shall be a route between the SDS sub-entity and the PC sub-entity; 
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the rh route shall be a route between the SS sub-entity and the SDS sub-entity. 
14.2.2 Protocol structure and protocol stack 

The CMCE is the layer 3 sub-layer for circuit mode CC, SS and SDS as described in clauses 11 , 12 and 
13 respectively. CMCE shall provide services to the user applications through service primitives defined 
for the following three SAPs: 

TNCC-SAP for CC services; 

TNSS-SAP for SS services; 

TNSDS-SAP for SDS. 

NOTE: Although there are separate SAPs defined for CC and SS, the protocol description is 
based on the CC service primitives, which contain a mixture of CC and SS 
parameters. 

CMCE shall obtain services from the underlying voice and data MLE through the LCMC-SAP. 
There shall be one instance of the CMCE entity per TSI family within the MS/LS. 
The CMCE is internally subdivided into four different sub-entities: 

CC; 

SS; 

SDS; and 

Protocol Control (PC). 

The information exchange between the CC and the SS sub-entities is defined in the supplementary 
service definitions. The structure is as shown in figure 19 below. 
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[NOTEff^ 



[NOTE2P 



ra route 
Jnote 1] 



[note 3]^ 



rb route 

^jNOTE2] 



rc route 

^J}jOTE3] 



1..n 



Call 
Control 



rg route 

K a 



1..n+1 

Supplementary 
Services 



rh route 

K a 



Short Data 
Service 



D-ALERT 
D-CALL PROCEEDING 
D-CALL RESTORE 
D-CONNECT 
D-CONNECT ACK 
D-DISCONNECT 
D-INFO 
D-RELEASE 
D-SETUP 
D-TX CEASED 
D-TX CONTINUE 
D-TX GRANTED 
D-TX INTERRUPT 
D-TX WAIT 
BREAK indication 
CLOSE indication 
OPEN indication 
REOPEN indication 
REPORT indication 
RESTORE confirm 
RESUME indication 



D-FACILITY 
CLOSE indication 
OPEN indication 
REPORT indication 



XL 



rd route 



U-ALERT 

U-CALL RESTORE 

U-CONNECT 

U-DISCONNECT 

U-INFO 

U-RELEASE 

U-SETUP 

U-TX CEASED 

U-TX DEMAND 

CANCEL request 

CONFIGURE request 

RESTORE request 



D-STATUS 
D-SDS DATA 
CLOSE indication 
OPEN indication 
REPORT indication 



re route 



U-FACILITY 
CANCEL request 
IDENTITIES request 



rf route 



U-STATUS 
U-SDS DATA 
CANCEL request 



Protocol 
Control 



Z7\ 



MLE-BREAK indication 
MLE -CLOSE indication 
MLE-OPEN indication 
MLE-REOPEN indication 
MLE-RELEASE indication 
MLE-REPORT indication 
MLE-RESUME indication 
MLE-UNITDATA indication! 



ri route 



MLE-CANCEL request 
MLE-CONFIGURE request 
MLE-IDENTITIES request 
MLE-RELEASE request 
MLE-RESTORE request 
MLE-UNITDATA request 



NOTE 1 : Service primitives for the TNCC-SAP are defined in clause 1 1 . 
NOTE 2: Service primitives for the TNSS-SAP are defined in clause 12. 
NOTE 3: Service primitives for the TNSDS-SAP are defined in clause 13. 



Figure 19: Block view of CMCE-MS 



14.2.3 



Addressing rules 



In addition to the normal TSI which is used in different forms in the initial call set-up messages (ITSI, 
GTSI, SSI), the CMCE entity can also use the call identifier for call handling. 

The call identifier can be used as a unique reference to a call between calling and called parties within one 
TETRA system. The call identifier is allocated at call set-up time by the SwMI. Once allocated, the call 
identifier shall be used in subsequent call related CMCE messages during that call. A new call identifier 
can be allocated to an ongoing call by the SwMI. 



14.2.4 CC, SS and SDS sub-entities 



The CMCE model describes the protocol behaviour of CC, SS and SDS functional entities. 
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14.2.4.1 CC sub-entity 

The CC process is a functional sub-entity which provides a set of procedures for the establishment, 
maintenance and release of circuit switched services. It provides support for the TETRA basic call 
signalling. The CC shall manage invocation of the SS-Access Priority. 

The CC process shall use the ra signalling route for communication with the user application (see 
clause 11) and the rd signalling route for communication with the protocol control process. The 
information exchange of SS related parameters needed for SS information exchange is not defined. 

There can be multiple instances of CC per CMCE entity. Depending on its physical capabilities an MS may 
be able to support up to four active concurrent circuit mode calls at the same time. 

14.2.4.2 SS sub-entity 

The SS process is a functional sub-entity which provides procedures for transfer of information related to 
SSs. The transfer of SS information is either call related or call unrelated. 

The SS processes shall use the rb signalling route for communication with the user application over the 
TNSS-SAP (see clause 12) and the re signalling route for communication with the protocol control 
process. Internal communication between the CC process and the SS process is outside the scope of this 
ETS. 

SSs related to a call in progress shall have a fixed relationship with the corresponding CC entity instance 
and these SS instances shall cease to exist after the CC instance ceases to exist. 

There shall be also a SS entity, which is not related to any calls in progress. That entity may use either a 
U/D-FACILITY PDU or any CC PDU, when appropriate, to exchange SS information between a MS and a 
SwMI. The facility field of the CC PDUs shall only be used to exchange SS information between a MS and 
the SwMI. 

14.2.4.3 SDS sub-entity 

The SDS process shall be a functional sub-entity which provides procedures for transfer of short data and 
status messages. The SDS entity shall also manage invocation of the SS- Access Priority for the short 
data PDU exchange. 

The SDS process shall use the rc signalling route for communication with the user application over the 
TNSDS-SAP (see clause 13) and the rf signalling route for communication with the protocol control 
process. 

The SDS entity shall not be related to any call and it shall provide SDS services independently of whether 
the SDS message is directed to a user application involved in an active CC call, or not. 

There shall only be one instance of SDS entity per CMCE entity. 

14.2.5 PC sub-entity 

The PC sub-entity shall provide the following functionality: 

PC shall act as an upwards/downwards router by discriminating the upper sub-entities within 
CMCE. The analysis of the content of the various information elements in the PDUs shall be done 
by the sub-entity which is responsible for and owns the individual elements. Outgoing PDUs shall be 
routed to the MLE in primitives; 

PC shall ensure that there is only one mobile originated call set-up in progress at any one time by 
only allowing one CC sub-entity at a time to be actively setting up a call until SwMI allocates a call 
identifier to that call or the call set-up is discarded; 

MLE shall give indications of the progress of the PDU transmission to PC by MLE-REPORT 
indications. PC shall be responsible for handling of general error procedures for the CMCE protocol; 
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PC shall use the signalling routes rd, re t rf for communication with the CC, SS and SDS sub- 
entities, and the ri signalling route for communication with the MLE over the LCMC-SAP; 

there shall only be one instance of PC per CMCE entity. 

1 4.2.6 I nternal routes 

The PDUs and local primitives are grouped per each sub-entity and internal route. 
From PC to CC on rd route: 
D-ALERT; 

D-CALL-PROCEEDING; 

D-CALL-RESTORE; 

D-CONNECT; 

D-CONNECT ACKNOWLEDGE; 

D-DISCONNECT; 

D-INFO; 

D-RELEASE; 

D-SETUP; 

D-TX-CEASED; 

D-TX-CONTINUE; 

D-TX-GRANTED; 

D-TX-INTERRUPT; 

D-TX-WAIT; 

BREAK indication; 

CLOSE indication; 

OPEN indication; 

REOPEN indication; 

REPORT indication; 

RESTORE confirm; 

RESUME indication. 

From CC to PC on rd route: 

U-ALERT; 

U-CALL-RESTORE; 

U-CONNECT; 

U-DISCONNECT; 

U-INFO; 

U-RELEASE; 

U-SETUP; 

U-TX-CEASED; 

U-TX-DEMAND; 

CANCEL request; 

CONFIGURE request; 

RESTORE request. 

From PC to SS on re route: 

D-FACILITY; 
CLOSE indication; 
OPEN indication; 
REPORT indication. 

From SS to PC on re route: 

U-FACILITY; 
IDENTITIES request; 
CANCEL request. 



NOTE 1: U/D-FACILITY PDUs are used to transport SS information, which is not related to any 
ongoing call or related to a call during SS-CC retention time after the call. 
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NOTE 2: SS information, which relates to an ongoing call is transported either as a predefined 
element in a CC PDU or as a facility element in a CC or in a U/D-INFO PDU (see 
subclause 14.7). 

From PC to SDS on rf route: 

D-STATUS; 
D-SDS-DATA; 
CLOSE indication; 
OPEN indication; 
REPORT indication. 

From SDS to PC on rf route: 

U-STATUS; 
U-SDS-DATA. 
CANCEL request. 

14.2.7 Intra-CMCE primitive summary 

The sub-entities inside CMCE shall be responsible for setting parameters in each PDU it is sending. 
These parameters are used in the lower layers in the transmission process. These parameters are not 
visible outside the MS protocol stack, but shall affect to the functions inside the protocol stack. 

14.2.7.1 Down link CC PDU parameters 

The following parameters shall accompany each PDU in addition to the PDU contents (SDU). The 
contents of the SDUs are defined in subclause 14.7. These parameters shall be valid for rd route (see 
subclause 17.3.4 for ri route parameters): 

received address type; 
received TETRA address; 
channel change response required. 

The D-CALL RESTORE PDU should be a SDU in the RESTORE confirm primitive and the parameters 
used in this primitive shall be: 

SDU; 

restoration result. 

14.2.7.2 Uplink CC PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents 
of the PDUs are defined in subclause 14.7. These parameters shall be valid for rd route (see 
subclause 17.3.4 for ri route parameters): 

endpoint identifier; 
layer 2 service; 
PDU priority; 
stealing permission; 
stealing repeats flag. 

The MS shall send the U-RESTORE REQUEST PDU as an SDU in the RESTORE request primitive. 
The parameters used in this primitive shall be: 
SDU; 

layer 2 service; 
PDU priority; 
stealing permission; 
stealing repeats flag. 
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14.2.7.3 Downlink SS PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents 
of the PDUs are defined in subclause 14.7. These parameters shall be valid for re route (see 
subclause 17.3.4 for ri route parameters): 

channel change response required; 
received address type; 
received TETRA address. 

1 4.2.7.4 Uplink SS PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents 
of the PDUs are defined in subclause 14.7. These parameters shall be valid for re route (see 
subclause 17.3.4 for ri route parameters): 

layer 2 service; 
PDU priority; 
stealing permission. 

14.2.7.5 Down link SDS PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents 
of the PDUs are defined in subclause 14.7. These parameters shall be valid for rf route (see 
subclause 17.3.4 for ri route parameters): 

received address type; 
received TETRA address. 

14.2.7.6 Uplink SDS PDU parameters 

Each PDU shall convey following information as parameters in addition to the PDU contents. The contents 
of the PDUs are defined in subclause 14.7. These parameters shall be valid for rf route (see 
subclause 17.3.4 for ri route parameters): 

layer 2 service; 
PDU priority; 
stealing permission. 

14.2.7.7 CMCE management primitives 

14.2.7.7.1 BREAK indication 

There are no parameters associated with this primitive. 

1 4.2.7.7.2 CANCEL request 

The parameter used in this primitive shall be: 
handle. 

14.2.7.7.3 CLOSE indication 

There are no parameters associated with this primitive. 
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14.2.7.7.4 CONFIGURE request 

The parameters used in this primitive shall be: 

add temporary GSSI; 

circuit mode type (see subclause 1 4.8.2); 

channel change accept; 

delete temporary GSSI; 

encryption flag; 

call identifier; 

endpoint identifier; 

simplex/duplex; 

slots per frame; 

switch U-plane on/off; 

Tx grant. 

1 4.2.7.7.5 IDENTITIES request 

The parameter used with this primitive shall be: 
list of GSSIs. 

14.2.7.7.6 OPEN indication 

There are no parameters associated with this primitive. 

14.2.7.7.7 REOPEN indication 

There are no parameters associate with this primitive. 

1 4.2.7.7.8 REPORT indication 
The parameter used in this primitive shall be: 

transfer result. 

1 4.2.7.7.9 RESUME indication 

There are no parameters associated with this primitive. 

14.3 Overview of services required by the CMCE 

In order to transfer messages over the air interface, CMCE shall use the services of the MLE, which in 
turn shall rely on the service from underlying layers. The services required from MLE shall be as described 
in clause 17. 

14.4 CMCE protocol states 

CMCE shall comprise 4 sub-entities each of them having a separate state transition diagram as shown in 
figures 20, 21, 22 and 23. 

Only the main states are shown. 
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14.4.1 States for PC 




MLE-CLOSE indication / ^ 




MLE-OPEN indication 



14.4.1.1 



All other PDUs 
and primitives 



Figure 20: State transition diagram for the PC sub-entity 
CLOSED 



This state exists after an MLE-CLOSE indication has been received from the MLE indicating that access 
to communication resources is no longer allowed and the PC sub-entity shall inform the CC f SS and SDS 
sub-entities with CLOSE indications. The PC sub-entity shall also enter state CLOSED after initial start up. 



14.4.1.2 



OPEN 



This is the normal state and indicates that a communication path to a peer entity is open. It is set after an 
MLE-OPEN indication has been received from the MLE. When PC receives a MLE-OPEN indication and 
goes to state OPEN, the CC, SS and SDS sub-entities shall be informed with OPEN indications. 
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14.4.2 



States for CC 



D-ALERT 

D-CALL PROCEEDING 
D-INFO 



MO_CALL 
SETUP 




TNCC-COMPLETE request 
TNCC-SETUP response (indiv) 
TNCC-TX request 
D-INFO 



(See also SUB-STATES) 



D-CONNEC 



(See also SUB-STATES) 



D-CONNECTACK (indiv). 
TNCC-SETUP response (group) 



D-RELEASE 
D-DISCONNECT 



Figure 21 : State transition diagram for the CC sub-entity 



A further subdivision of the main states MT-CALL-SETUP and CALL-ACTIVE belonging to the CC sub- 
entity may be considered as detailed in figures 22 and 23. 
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CALL 
(DISCONNECT, 



Txxx time out , A fclv/ 

TNCC-RELEASE request / ANY 

■< — | CALL ACTIVE ) 

STATE 



D-RELEASE V 



BREAK ind 



RESUME ind 



'Txxx time out 
TNCC-RELEASE 
request 



BREAK 



IDLE 



D-SETUP 
TNCC-SETU 
request 



NT 



D-RELEASE 
D-DISCONNECT 
CLOSE indication 
REOPEN indication 



TNCC-TX req (cease) 
D-CALL RESTORE 
D-TX GRANTED 
D-TX CEASED 
D-TX INTERRUPT 
D-INFO , 




D-RELEASE 
D-DISCONNECT' 
CLOSE indication 
REOPEN indication 



D-TX GRANTED 
D-TX CONTINUE 



Figure 22: Sub state transition diagram for the CALL-ACTIVE state 
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Figure 23: Sub state transition diagram for the MT-C ALL-SETUP state 



14.4.2.1 IDLE 

This is the normal state when no calls exist and indicates that the CC sub-entity is available to handle a 
call set-up. This is the state that CC shall enter after initial start up. 

14.4.2.2 MO-CALL-SETUP 

This state exists when a MS/LS originated call set-up has been initiated but the call has not been 
established. It exists after a U-SETUP PDU has been sent as the result of the receipt of a TNCC-SETUP 
request until a D-CONNECT PDU is received indicating that the call set-up is successful. If the call set-up 
is unsuccessful or the user application disconnects the call the CC sub-entity shall leave this state. 

14.4.2.3 MT-CALL-SETUP 

This state exists during a call set-up where the CC sub-entity is the call terminating CC sub-entity. It exists 
after the receipt of a D-SETUP PDU, until the receipt of a D-CONNECT ACKNOWLEDGE PDU, for 
point-to-point calls only, or receipt of a TNCC-SETUP response for point-to-multipoint calls only,. The 
MT-CALL SETUP state is also left if the call set-up is unsuccessful, or if the user application rejects the 
call. 

14.4.2.4 CALL ACTIVE 

This state exists when the call has been established. 

1 4.4.2.5 CALL DISCONNECT 

This state exists when an established call is in the progress of disconnecting. It exists after the receipt of a 
TNCC-RELEASE request from the user application, or if a timer initiated disconnection occurs, until either 
a D-RELEASE PDU is received, or the call disconnect timer expires. 
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14.4.2.6 



WAIT 



The state exists if there is a temporary interruption to the call. The CC shall enter this state upon receipt of 
a D-TX-WAIT PDU and remain in this state until a D-TX-CONTINUE PDU or D-TX GRANTED PDU is 
received, or the call is disconnected. 



14.4.3 



States for SS 



There shall only exist 2 general generic states for the SS sub-entity. Each individual service shall then 
have its own state transition diagrams associated with its protocol. 




D-FACILITY 
FACILITY indication 
OPEN indication 
CLOSE indication 
BREAK indication 



TNSS-SERVICE response 
TNSS-SERVICE request 
TNSS-INFO response 
TNSS-INFO request 



REPORT indication 
CLOSE indication 
Txxx time out 



D-FACILITY 
FACILITY indication 




Figure 24: State transition diagram for the SS sub-entity 
14.4.4 States for SDS 

There shall only exist 2 generic states for the SDS sub-entity. 

D-SDS DATA 
D-STATUS 
OPEN indication 
CLOSE indication 

— ^ 




TNSDS-STATUS request 
TNSDS-UNITDATA reques 



REPORT indication 
CLOSE indication 
Txxx time out 



D-SDS DATA 
D-STATUS 




Figure 25: State transition diagram for the SDS 
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14.5 



Procedures 



In this protocol the routing of PDUs and primitives is implicit by the PDU and primitive name as defined in 
subclause 14.2. 

The timers in the following procedures are: 

started - meaning that the timer shall start to measure time as indicated in the parameter value 
T3xx independently of the current timer count; or 

restarted - meaning that the timer shall continue to measure time as indicated in the current timer 
count; or 

stopped - meaning that the timer shall be stopped at the current timer count. 

Depending on timer T3XX the starting value shall either be pre-defined or dynamically set by air interface 
protocol procedures. 



NOTE 1 
NOTE 2 



In IDLE state all timers T3XX are stopped and whenever a timer is started it will get a 
proper value as stored, or from a PDU as appropriate. 



14.5.1 



There is no call identifier associated to a CC instance in IDLE state. 
Individual CC procedures 



The CC procedures handled by the CC sub-entity shall be applicable for both speech and data circuit 
mode calls. Individual speech and data circuit mode calls shall be set-up as point-to-point calls. The 
specification shall be applicable for the procedures and states that reside in the MS/LS. 



14.5.1.1 



Call set-up procedures 



tncc.setup req 


U- SETUP p 


mle_unitdata req ^ 


Start T303 

tncc_proceed ind 


4 report ind 


4 mte_report ind 


4 report ind 


4 mle_report ind 


^ report ind 


^ mle_report ind 


_ D-CALL 


^mte_unitdata ind 


4 mle_unitdata ind 


* PROCEEDING 
D-INFO 


StopT303 
Start T302 

tncc_notify ind 


^mte_unrtdata ind 


4 D-ALERT 


* (Start T302) 

tnoc_alert ind 


^mle_unitdataind 


4 D-CONNECT 


Start T302 

tncc.setup con 


m!e_con5gure req^ 


configure req ^ 


* Stop T302 
Start T310 







mle SwMI mle 



mle unttdata ind ^ 


D-SETUP p 


tncc_setup ind ^ 


4 m!e_unitdata req 


„ U-ALERT 


4 tncc_setup_res 


^tncc_complete req 


< 

report ind ^ 


mle_report ind ^ 


mle_report ind 


report ind ^ 


mte_report ind ^ 


report ind ^ 


4 mte_unitdata req 


4 U-CONNECT 


Start T301 

tncc_oomplete oon^ 


report ind ^ 


mte_report ind ^ 


mle_report ind ^ 


report ind ^ 


mle_report ind ^ 


report ind ^ 


mle unttdata ind ^ 


D-CONNECT 


^mle_configure req 


ACKNOWLEDGE 
4 confiaure req 


StopT301 
Start T3 10 







Figure 26: Individual call set-up scenario using on/off hook signalling 
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tncc_setup req 


U- SETUP ^ 


mle_unttdata req ^ 


Ctart *Mfrt 
9l3rl IJUJ 

tncc ^proceed ind 


^ report ind 


^mle_report ind 


^ report ind 


^ mle_report ind 


^ report ind 


^ mle_report ind 


D-CALL 


^ mle_unitdata ind 


mle_unitdata ind 


* PROCEEDING 
^ D-CONNECT 


* Stop T303 
Start T302 

M tncc setup con 


mle_configure req^ 


configure req ^ 


* Stop T302 
Start T310 







SwMl 



mle unttdata ind ^ 


D-SETUP 


tncc_setup ind 


: ^ 

mlejjnitdata req 


^ U-CONNECT 


^ tncc_setup res 


Start T301 
tncc_complete ind^ 


report ind 


mle_report ind ^ 


mle_report ind ^ 


report ind ^ 


mle_report ind ^ 


report ind 


mle unitdata ind ^ 


D-CONNECT 


^mle_configure req 


ACKNOWLEDGE* 
^ confiqure req 


Stop T301 
Start T310 







14.5.1.1.1 



Figure 27: Individual call set-up scenario using direct set-up signalling 
Incoming call 



Notification of the arrival of an incoming call to the CC sub-entity shall be made by the reception of a 
D-SETUP PDU which shall be delivered to the user application in a TNCC-SETUP indication via the 
TNCC-SAP. If the user application can support the call it shall immediately return a TNCC-SETUP 
response otherwise it shall return a TNCC-RELEASE request (see subclause 14.5.1 .1 .5). 

On receipt of a D-SETUP PDU the CC sub-entity shall enter state MT-CALL-SETUP and take the 
following actions, which are dependent upon the information contained within the D-SETUP PDU: 

the call identifier shall be used as the reference to this call in subsequent PDUs during the call; 

it shall be indicated to the called MS/LS in the D-SETUP PDU if on/off hook signalling or direct 
set-up signalling is used for this call set-up; 

if on/off hook signalling is requested and the CC receives a TNCC-SETUP response indicating that 
the called user application has accepted on/off hook signalling, the CC shall send a U-ALERT PDU 
indicating that the called party is alerted, see figure 26 right hand side. The CC sub-entity shall 
remain in state MT-CALL-SETUP; 

when on/off hook signalling is used and the CC receives a TNCC-COMPLETE request indicating 
that the called user application has answered, the CC shall send a U-CONNECT PDU and start 
timer T301. The CC sub-entity shall remain in state MT-CALL-SETUP. Upon receipt of a 
D-CONNECT ACKNOWLEDGE PDU, the CC shall inform the user application with a 
TNCC-COMPLETE confirm, enter state CALL-ACTIVE, stop timer T301 and start timer T310, see 
figure 26 right hand side. The D-CONNECT-ACKNOWLEDGE PDU shall contain an indication as to 
which party is permitted to transmit. The CC sub-entity shall send a CONFIGURE request for lower 
layer configuration; 

if direct set-up signalling is used and the CC receives a TNCC-SETUP response indicating that the 
called user application has accepted direct call set-up signalling, the CC shall send a U-CONNECT 
PDU indicating that the MS/LS is ready for immediate communication, and shall start timer T301 . 
Upon receipt of the U-CONNECT message the SwMl should send a 
D-CONNECT ACKNOWLEDGE PDU in return. The CC sub-entity shall then inform the user 
application with a TNCC-COMPLETE indication and shall enter state CALL-ACTIVE, stop timer 
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T301 and start timer T310, see figure 27 right hand side. The D-CONNECT ACKNOWLEDGE PDU 
shall contain an indication as to which party is permitted to transmit. The CC sub-entity shall send 
a CONFIGURE request for lower layer configuration; 

if transmission is not granted but the D-CONNECT ACKNOWLEDGE PDU contains an indication 
that the MS/LS is allowed to request transmission permission, the CC shall follow the transmission 
control procedures outlined in subclause 14.5.1.2.1; 

where the called MS/LS is unable to accept the request for a basic service, it may according to the 
rules stated below, offer a different basic service to the calling party. The offered value shall be 
indicated in the U-CONNECT or U-ALERT PDU. Where the called MS/LS is unable to offer a 
different service according to the rules below then the call shall be rejected using a 
U-DISCONNECT PDU as defined in subclause 14.5.1 .1 .5, e.g. if circuit mode data is requested but 
the terminal cannot support data. 

for circuit mode unprotected bearer services: 

if 28,8 kbit/s requested, 21 ,6 kbit/s, 14,4 kbit/s or 7,2 kbit/s may be offered; 
if 21 ,6 kbit/s requested, 14,4 kbit/s or 7,2 kbit/s may be offered; 
if 14,4 kbit/s requested, 7,2 kbit/s may be offered; 

for circuit mode protected (low) bearer services: 

if 19,2 kbit/s requested, 14,4 kbit/s, 9,6 kbit/s or 4,8 kbit/s may be offered; 

if 14,4 kbit/s requested, 9,6 kbit/s or 4,8 kbit/s may be offered; 

if 9,6 kbit/s requested, 4,8 kbit/s may be offered; 

if interleaving depth N = 8 requested, N = 4 or N = 1 may be offered; 

if interleaving depth N = 4 requested, N = 1 may be offered; 

for circuit mode protected (high) bearer services: 

if 9,6 kbit/s requested, 7,2 kbit/s, 4,8 kbit/s or 2,4 kbit/s (high) may be offered; 

if 7,2 kbit/s requested, 4,8 kbit/s or 2,4 kbit/s (high) may be offered; 

if 4,8 kbit/s requested, 2,4 kbit/s (high) may be offered; 

if interleaving depth N = 8 requested, N = 4 or N = 1 may be offered; 

if interleaving depth N = 4 requested, N = 1 may be offered; 

if the called MS/LS is requested to support a duplex call and is unable to do so, then it shall offer a 
simplex call by setting the simplex/duplex element accordingly in either the U-ALERT or 
U-CONNECT PDU; 

if the called MS is requested to use direct call set-up and it is unable to support this, but does 
support on/off hook signalling, then it shall offer this service by setting the hook method element 
accordingly in the U-ALERT PDU; 

if the called MS is requested to use on/off hook signalling and is unable to support this, but does 
support direct call set-up, then it shall offer this service by setting the hook method element 
accordingly in the U-CONNECT PDU; 

if the called user application during the call set-up cannot continue to support of the call for other 
reasons that those stated above the request for call set-up shall be rejected by issuing a TNCC- 
RELEASE request. The request to release the call set-up shall be mapped to a U-DISCONNECT 
PDU and follow the procedure defined in subclause 14.5.1.3. 

During the call set-up phase, the SwMI may send the D-INFO PDU to prolong the call set-up time. If the 
CC in the called MS/LS receives an D-INFO PDU containing a Call time-out, set-up phase element the CC 
shall start timer T301 using the specified value. 

14.5.1.1.2 Outgoing call 

To initiate the call establishment, the user application shall transfer a TNCC-SETUP request primitive 
across the TNCC SAP to the CC sub-entity. The TNCC-SETUP request shall be handled by a CC sub- 
entity instance that is in state IDLE. 
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The CC shall select a PDU priority based on the requested access priority value as defined in subclause 
14.5.6.2. The CC shall convert the TNCC-SETUP request into a corresponding U-SETUP PDU and send 
it. The CC sub-entity shall then enter the MO-CALL-SETUP state and start timer T303. 

The TNCC-SETUP request includes parameters that allow the user application to select a target grade of 
service and a lowest acceptable grade of service. These allow the called user application or SwMI to e.g. 
accept a lower bit rate or interleaving depth for a circuit mode data call than that requested. The 
parameters shall be as defined in clause 1 1 . 

The following describes the normal call set-up procedures: 

the progress of the transmission of the U-SETUP PDU may be reported to the CC in one or more 
REPORT indications. If the PDU transfer has failed, the CC shall stop timer T303, inform the user 
application with a TNCC-RELEASE indication and return to state IDLE; 

the SwMI may respond to the receipt of the U-SETUP PDU with a D-CALL PROCEEDING PDU 
indicating that the SwMI has received all information concerning the call set-up necessary to effect 
the call establishment. On reception of the PDU, the CC shall inform the user application with a 
TNCC-PROCEED indication. In the case where On/Off Hook Signalling is requested or the called 
user application selects that method and alerting information is ready at the time when the D-CALL 
PROCEEDING PDU should have been sent, the SwMI may respond with a D-ALERT PDU instead 
of the D-CALL-PROCEEDING PDU. Also if the call through connection is ready at the time when 
the D-CALL PROCEEDING PDU should have been sent, the SwMI may send a D-CONNECT PDU 
instead. On receipt of any of the above PDUs, Timer T303 shall be stopped, see figure 26 left hand 
side; 

the D-CALL PROCEEDING, D-ALERT or D-CONNECT PDU shall contain a Call Identifier which 
shall be used as the reference to this call in subsequent PDUs for the duration of the call; 

on reception of the D-CALL-PROCEEDING PDU the CC shall start timer T302, see figure 26 left 
hand side. The CC sub-entity shall remain in state MO-CALL-SETUP; 

if on/off hook signalling is requested and the CC receives a D-ALERT PDU, the CC shall inform the 
user application by issuing a TNCC-ALERT indication; 

on reception of a D-ALERT PDU, the timer T302 shall be started using the specified value, see 
figure 26 left hand side; 

during the call set-up phase, the SwMI may send the D-INFO PDU to prolong the call set-up time. 
Upon reception of a D-INFO PDU containing Call time out, set-up phase element, the timer T302 
shall be started using the specified value; 

when a D-CONNECT PDU is received, the CC shall send a CONFIGURE request for lower layer 
configuration and inform the user application with a TNCC-SETUP confirm and enter state CALL- 
ACTIVE. The timer T302 shall be stopped, and timer T310 shall be started, see figure 26 left hand 
side. The D-CONNECT PDU shall contain an indication which party is permitted to transmit; 

If transmission is not granted but the D-CONNECT PDU contains an indication that the MS/LS is 
allowed to request transmission permission it shall follow the transmission control procedures 
defined in subclause 14.5.1 .2.1 ; 

where the D-CALL PROCEEDING, D-CONNECT or the D-ALERT PDU indicates that the offered 
service is different to the one requested, and if the service offered is acceptable to the CC sub- 
entity according to the selected lowest acceptable service in TNCC-SETUP request, the call shall 
continue. If the service is not acceptable, then the call shall be disconnected and the CC shall enter 
IDLE state, refer to subclause 14.5.1 .3. 

EXAMPLE: If the user application has requested a 28,8 kbit/s circuit mode data, but 

indicated that any data rate equal to or greater than 14,4 kbit/s is acceptable, 
then if a data rate of 14,4 kbit/s is offered the call shall continue. If a data rate of 
less than 14,4 kbit/s is offered (i.e. 7,2 kbit/s) then the call shall be 
disconnected. 
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14.5.1.1.3 Colliding calls 

Call collisions can occur when both the SwMI and the MS/LS simultaneously send a D/U-SETUP PDU. 
Two call set-ups are colliding when a D-SETUP PDU is received within the window where the CC waits for 
a Call Identifier from the SwMI after a U-SETUP PDU has been issued. If this occurs and the MS/LS 
cannot support more concurrent calls, the MS/LS shall behave as follows: 

if the MS wishes to keep its own call attempt then it shall respond to the incoming call with a U- 
DISCONNECT PDU with a disconnect cause "called party busy"; or 

if the MS wishes to accept the incoming call then the CC shall accept the call as defined in 
subclause 14.5.1.1.1. The CC shall also send a CANCEL request to the lower layers to cancel the 
sending of the U-SETUP PDU. If the lower layers indicate that the PDU has already been 
completely sent, then the CC shall send a U-DISCONNECT PDU for its own call set-up. 

Another case of call collision may sometimes be detected and resolved by the SwMI. If the colliding calls 
are call set-up attempts between the same user applications and the requested basic services are the 
same, then the SwMI may merge the calls. The SwMI should inform both parties by a D-CONNECT PDU 
with an amalgamation indication that the calls are merged together, see the call ownership element. The 
CC should pass this information on to the application in the TNCC-SETUP confirm. 

1 4.5.1 .1 .4 Unsuccessful call set-up 

Unsuccessful call set-up shall refer specifically to those instances where a circuit mode connection was 
not successfully established. It shall not refer to call disconnection or call rejection. If a PDU is not 
responded to prior to the expiry of the corresponding timer the procedure in subclause 14.5.1.3.4. shall 
apply. All timers available are listed in subclause 14.6. 

When CC receives a REPORT indication, indicating that the lower layers have not been successful (failed 
transfer) in the sending of any of the call set-up PDUs, then the CC sub-entity shall return to state IDLE 
and shall inform the user application with a TNCC-RELEASE indication accompanied with a cause of the 
disconnection. 



1 4.5.1 .1 .5 Call rejection 
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Figure 28: Individual call set-up phase - called user application rejects the call 

If the user application cannot support an incoming call as defined in 14.5.1.1.1, it shall immediately 
transfer a TNCC-RELEASE request to the CC sub-entity. The CC sub-entity shall send a 
U-DISCONNECT PDU along with the disconnection cause "Call Rejected by the called party", see 
figure 28. The CC sub-entity shall then change to state IDLE. 
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If the SwMI sends the D-RELEASE PDU as the first response to the calling MS, then it 
should contain the dummy call reference. 



NOTE: 

1 4.5.1 .2 Call maintenance procedures 



The call maintenance procedures shall only be applied when the MS/LS is in state CALL-ACTIVE. The 
main state CALL-ACTIVE can comprise several sub-states which are presented in informative figure 22. 



14.5.1.2.1 
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for the purposes of clarity, only one instance of mle jeport is shown 

Figure 29: Individual call request-to-transmit 



a) Request-to-Transmit 

The SwMI shall fully control which MS/LS is allowed to transmit. To facilitate this the MS/LS shall 
request permission to transmit from the SwMI and shall receive a permission to transmit before the 
MS/LS may begin a circuit mode U-plane transmission. If the SwMI allows, in a "transmission 
request permission" element, then the MS/LS may request a permission to transmit even if the 
other party is already transmitting. In this case the SwMI should normally wait for that party to finish 
the transmission before granting the other user application. Pre-emptive priority requests are dealt 
with in subclause 14.5.1.2.1 f). 

If on/off hook signalling is used, the normal mode of operation shall be that the called MS shall be 
given permission to transmit by setting the transmission grant element accordingly in the D-SETUP 
PDU. However, if desired, the calling MS can ask for permission to transmit by setting the "request 
to transmit" bit accordingly in the U-SETUP PDU. This is dealt with in subclauses 14.5.1.1.1 and 
14.5.1.1.2. 
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If direct set-up signalling is used, the normal mode of operation shall be that the calling MS shall be 
given the permission to transmit. However the calling user application may in the U-SETUP PDU 
allow the called user application to request the permission to transmit first by setting the "request to 
transmit" bit accordingly in the U-SETUP PDU. 

When a user application within a call wants to transmit, a TNCC-TX request shall be sent to the CC 
via the TNCC-SAP. The CC shall send this request in a U-TX-DEMAND PDU, see figure 29. The 
TX demand priority should be set to low or high priority, unless this is a pre-emptive request, see 
subclause 14.5.1.2.1 f). 

The progress of the transmission of the U-TX DEMAND PDU shall be given locally to the CC in one 
or more REPORT indication primitives. If the CC receives a REPORT indication with a failed 
transmission indication as a response to the sending of the U-TX DEMAND PDU the CC shall 
inform the user application by a TNCC-TX confirm primitive. 

If a user application wants to withdraw its request-to-transmit before it has been granted, a TNCC- 
TX request shall be issued to the TNCC-SAP. The CC shall send this request in a U-TX-CEASED 
PDU or the previous request should be cancelled locally if still possible. The CC shall send the 
U-TX CEASED PDU with the stealing permission set to "immediate stealing- and stealing repeats 
flag set, so that the permission to transmit will be released immediately if allocated. 

b) Response to Request-to-Transmit 

During the call set-up phase. These procedures are dealt with in subclauses 14.5.1.1.1 and 
14.5.1 .1 .2. The MS/LS given permission to transmit shall start timer T31 1 . 

During a call in progress and when SwMI has decided which MS/LS shall be given permission to 
transmit, the SwMI shall send a D-TX GRANTED PDU to the granted MS/LS with the transmission 
grant element set to "transmission granted". The CC sub-entity shall send this information further on 
to the user application in a TNCC-TX confirm primitive. The other MS/LS involved in the call shall 
also be informed with a D-TX GRANTED PDU indicating that transmission has been granted to 
another user. This CC sub-entity shall send this information further on to the user application in a 
TNCC-TX indication primitive, see figure 29. 

If the SwMI rejects the transmission request this shall be indicated to the MS/LS concerned by the 
"transmission not granted" parameter value in the D-TX GRANTED PDU. 

If the SwMI places the transmission request in a queue this shall be indicated to the MS/LS 
concerned by the "transmission request queued" parameter value in the D-TX-GRANTED PDU. 
The MS/LS can then assume that the request-to-transmit will be held in the queue until it is either 
granted by the SwMI or withdrawn by the MS/LS, or the MS/LS receives a D-TX GRANTED PDU 
containing the "transmission not granted" parameter value. 

On reception of a D-TX-GRANTED PDU indicating "transmission granted" or "transmission granted 
to another user", the CC sub-entity shall issue a CONFIGURE request primitive. The primitive shall 
carry as a parameter whether the transmit permission has been granted to this MS/LS and a 
parameter to switch the U-Plane on. The MS/LS given permission to transmit shall start timer T31 1 . 

If the CC sends a U-TX-DEMAND PDU whilst the other MS is transmitting, then the SwMI should 
normally wait for that party to finish the transmission (identified by the receipt of a U-TX-CEASED 
message) before granting transmission to the other user application. On receipt of the 
U-TX DEMAND PDU, the SwMI may send a D-TX GRANTED PDU indicating whether the 
request-to-transmit is queued or rejected. Pre-emptive requests are dealt with under subclause 
14.5.1.2.1 0- 

c) Permission to Transmit withdrawn 

The SwMI may decide to interrupt transmission when resources are required for another call or 
when the SwMI requires that the call should temporarily pause. In this case the SwMI should send a 
D-TX-WAIT PDU to each MS/LS (permitting or denying transmission requests according to the 
"transmission request permission" element). Upon receipt of the D-TX WAIT PDU, the CC sub- 
entity shall send a TNCC-TX indication to the user application indicating that the transmission is 
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waiting. The CC shall stop timer T311 if activated, enter state WAIT and send a CONFIGURE 
request to switch the U-Plane off. The MSs shall obey any layer 2 channel allocation information 
and await further instructions on the channel that they have been directed to. 

If a request-to-transmit has been queued at the time when the D-TX WAIT PDU is received, the MS 
shall be allowed to withdraw its request-to-transmit by means of the U-TX-CEASED PDU as 
described in subclause 14.5.1.2.1 e). 

d) Permission to Continue with withdrawn call 

When the SwMI has decided that the call can continue, the SwMI should send a D-TX-CONTINUE 
PDU to each MS/LS. When the CC sub-entity receives the notification of the continuation of the call 
in a D-TX-CONTINUE PDU it shall return to state CALL-ACTIVE. 

The D-TX-CONTINUE PDU shall contain an indication (the continue element) to specify whether 
the same transmission permission applies as at the time of the interruption. If the continue element 
is set to "continue", and if the MS/LS was either transmitting or receiving traffic when it received the 
D-TX WAIT PDU, then the CC sub-entity shall send a CONFIGURE request to switch the U-plane 
on. The MS/LS granted permission to transmit shall start timer T311. If the continue element is set 
to "not continue", or if the MS/LS was neither transmitting nor receiving traffic when it received the 
D-TX WAIT PDU, then the U-plane shall not be switched on and the MS/LS shall assume that any 
previous transmission permission no longer applies. 

If the D-TX-CONTINUE PDU contains an indication that the MS/LS is allowed to request 
transmission permission, it may follow the transmission control procedures described in subclause 
14.5.1.2.1 a). 

If an MS/LS has requested permission to transmit during the period when the transmission was 
withdrawn, the SwMI should first send a D-TX-CONTINUE to each MS/LS and then a D-TX 
GRANTED to each MS/LS allocating transmission permission as described in 
subclausel 4.5.1 .2.1 b). 

If the MS/LS is in state WAIT and it receives a D-TX GRANTED PDU then it shall behave as if it 
had previously received a D-TX CONTINUE PDU with the continue element set to "not continue". It 
shall then obey the instruction in the D-TX GRANTED PDU. 

e) End of Transmission 

At the end of a transmission, the user application shall send a TNCC-TX request to the TNCC-SAP 
indicating ceased transmission. The CC sub-entity shall send this information in a U-TX-CEASED 
PDU, remain in state CALL-ACTIVE and stop timer T311. The CC shall send the U-TX CEASED 
PDU with the stealing permission set to "immediate stealing" and the stealing repeats flag set. Upon 
receipt of the U-TX-CEASED PDU, the SwMI normally sends a D-TX-CEASED PDU to each MS/LS 
informing them that the transmission has now ceased. 

Upon reception of a D-TX-CEASED PDU, the CC shall send this information further on to the user 
application in a TNCC-TX indication (transmission ceased). The CC sub-entity shall send 
a CONFIGURE request to the lower layers to switch the U-Plane off. 

Also, if the CC that is sending the U-TX CEASED PDU receives a REPORT indication of either 
successful or unsuccessful transmission of that PDU by the lower layers, then it shall behave as if it 
had received a D-TX CEASED PDU i.e. it shall send a TNCC-TX indication (transmission ceased) 
to the user application and shall send a CONFIGURE request to the lower layers to switch the 
U-Plane off. 

If there was a request for transmission already queued in the SwMI when the U-TX-CEASED PDU 
was received, then the SwMI should send a D-TX GRANTED PDU to each MS/LS as described in 
subclause 14.5.1.2.1 b), without sending an explicit D-TX-CEASED PDU. The CC sub-entity shall 
send a CONFIGURE request to the lower layers to indicate the change in the transmit permission. 
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f) Stop Transmission order 

If, during the course of a transmission, a MS/LS wishes to interrupt the transmitting MS/LS, it shall 
send a U-TX-DEMAND PDU indicating the wanted level of pre-emptive priority in the TX demand 
priority element. The SwMI may then send a D-TX-INTERRUPT PDU to the MS that currently has 
the permission to transmit. Upon reception of a D-TX-INTERRUPT PDU, the CC shall stop 
transmission and remain in state CALL-ACTIVE, stop timer T311, send a TNCC-TX indication 
primitive to the user application indicating transmission interrupt and send a CONFIGURE request 
to lower layers to indicate the loss of transmit permission. The SwMI should then send a 
D-TX-GRANTED PDU to the requesting MS/LS indicating that the permission to transmit has been 
awarded as described in subclause 14.5.1.2.1 b). 

g) Call continuation 

The SwMI may decide to change the call time-out time by sending a D-INFO PDU with a new T310 
value. Upon reception of the D-INFO PDU containing the "call time-out" element, T310 shall be 
started using the defined value. 

The SwMI may also choose to reset the call time-out time and start it again using the current 
defined value. Upon reception of the D-INFO PDU with the "reset call time-out timer" element 
indicating that T31 0 shall be reset, T31 0 shall be started using the value defined earlier. 

In either case, the Timer value shall be sent further on to the application in aTNCC-NOTIFY 
indication primitive. 

14.5.1.2.2 Call status information procedures 

The D-INFO PDU can be used for carrying call status messages from SwMI to the MS/LS. When a 
D-INFO PDU is received, depending on the notification, the following actions are taken by CC: 

a) call in queue 

when the SwMI has put a call into a queue it may send a D-INFO PDU. If the D-INFO PDU contains 
a value for the call time-out, set-up phase, the CC shall start timer T301 or T302, as appropriate, 
using the specified value. The CC shall send the information to the application in a TNCC-NOTIFY 
indication primitive. If the call is queued at call set-up time the D-INFO PDU should be preceded by 
a D-CALL PROCEEDING PDU. 

b) call is proceeding 

this may be sent to the calling user application during the call set-up phase to indicate e.g. that the 
call set-up time through a gateway will be longer than for a normal call set-up time. The information 
that the timer value shall be changed is made available to the CC sub-entity in the D-INFO PDU. 
The CC shall start T302 with the indicated timer value. The CC shall send the information further on 
to the application in a TNCC-NOTIFY indication primitive. 

c) SwMI is paging called user 

when the SwMI is paging a called user, e.g. when the called user is on another network, the SwMI 
may send a D-INFO PDU with the call status parameter indicating this situation. If the D-INFO PDU 
contains a value for the call time-out, call set-up phase element, the CC shall start timer T302 using 
the specified value. 

14.5.1.2.3 Call modification procedures 

The MS/LS service user may modify the service of an existing call. To initiate a modification the user 
application shall issue a TNCC-MODIFY request primitive and the CC sub-entity shall send a U-INFO 
PDU and wait for a D-INFO PDU from the SwMI before changing any of the current service parameters. 
The SwMI should not send D-INFO to modify a service while an ongoing U-plane transmission is in 
progress. 

When a service has been changed by the SwMI, e.g. when a point-to-point call has been changed to a 
point-to-multipoint call, the SwMI should indicate this to the calling and called parties by sending a D-INFO 
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PDU. Upon reception of a D-INFO PDU the CC sub-entity shall send it to the application in a 
TNCC-MODIFY indication primitive. Finally the CC shall send a CONFIGURE request primitive for lower 
layer configuration. 

if the call has changed from point-to-point to point-to-multipoint, a temporary group address and a group 
call reference number (Call ID) shall be given. The new group call reference number can be the current 
Call ID of the including party. 

The service may be changed between any combination of one or more of the following: 
duplex operation may be changed to simplex operation, or 
simplex operation may be changed to duplex operation; 
a point-to-point call may be changed to a point-to-multipoint call; 
a clear call may be changed to an encrypted call, or 
an encrypted call may be changed to a clear call; 
a 4-slots per frame call may be changed to a 1 -slot, 2-slot or 3-slot call; 
a 3-slot call may be changed to a 1 -slot or 2-slot call; 
a 2-slot call may be changed to a 1 -slot call; 

a circuit mode type (TCH/S, TCH/7.2, TCH/4.8 or TCH/2.4) may be changed to a different circuit 
mode type. 

The encryption state of each transmission, defined using D-TX GRANTED, can be set independently by 
the encryption control element in the U-TX-DEMAND PDU. It is also possible to change between the 
circuit mode speech teleservice and a circuit mode unprotected (speech, encrypted) bearer service. The 
SwMI should not change the requested encryption state in the responding D-TX-GRANTED PDU from 
that requested in the U-TX-DEMAND PDU. 

If the MS/LS cannot support a new service combination, indicated by D-INFO, D-TX GRANTED or D-TX 
INTERRUPT, the user application or the CC, as appropriate, shall disconnect the call (see 
subclause 14.5.1.3.1). The U-DISCONNECT PDU shall contain disconnection cause "requested service 
not available". 



14.5.1.2.4 
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Figure 30: Individual call - successful call restoration 
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Figure 31 : Individual call - unsuccessful call restoration 

The responsibility of the procedure shall be to restore the call when the temporary break condition has 
been resolved by lower layers. 

When the CC receives a BREAK indication, then the CC sub-entity shall try to restore the call as 
described in this subclause; 



when the CC receives a BREAK indication, the CC shall send a CONFIGURE request to switch the 
U-plane off as described in subclause 14.5.1.4 and remain in state CALL-ACTIVE; 

if the CC receives a RESUME indication indicating that the C-plane may now be used again, it shall 
issue a U-CALL RESTORE PDU in a RESTORE request primitive containing the SSI or TSI of the 
other party in the individual call and the call identifier of the call which CC wants to restore. CC shall 
start timer T306 and wait for D-CALL-RESTORE PDU; 

when the CC receives a D-CALL-RESTORE PDU in a RESTORE indication primitive, timer T306 
shall be stopped, and the call shall be resumed with the new parameters, see figure 30. If 
appropriate the CC shall issue a CONFIGURE request using the procedure in subclause 14.5.1.4. 

On expiry of Timer T306, the procedure defined in subclause 14.5.1 .3.4 shall apply. 

If the call cannot be resumed the CC should receive a REOPEN indication primitive indicating that the call 
is lost. The CC shall then stop Timer T306 and return to state IDLE, and it shall send a TNCC-RELEASE 
indication to the user application with the cause of disconnection, see figure 31 . 

If there is more than one circuit mode call active at the time when the MLE-BREAK indication was 
received, each call shall be restored separately and hence U-CALL RESTORE and D-CALL RESTORE 
PDUs shall be exchanged one by one for each call. 



1 4.5.1 .2.5 DTMF procedures 



When a user application requires to transfer DTMF digits to another user application during a circuit mode 
call, it shall issue a TNCC-DTMF request primitive to the CC entity. CC shall send this request as a 
U-INFO PDU with the DTMF digits encoded as DTMF parameter values. The SwMI should then forward 
the DTMF digits to the addressed MS/LS in a D-INFO PDU. 

On the reception of a D-INFO PDU the CC shall forward the DTMF digits to the user application in a 
TNCC-DTMF indication. 

The U-INFO PDU may be addressed to a gateway. In this case, the receiving user application can be for 
example, either an external network subscriber application or a gateway that uses two stage dialling to 
set-up calls to external networks. 
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14.5.1.2.6 



Calls to and from external subscribers 



An MS/LS can make a call to a subscriber in an external network using a gateway. The call set-up 
message shall address the gateway using a particular SSI as the called party address and the U-SETUP 
PDU shall contain the external network subscriber number in the corresponding element. The gateway 
shall then set-up the call to the external network subscriber using that number without further call set-up 
messages from the calling MS/LS. 

An alternative mechanism for calling external network subscribers is possible using DTMF procedures 
and a two stage signalling method. In this case, an MS may omit the external network subscriber number 
in the U-SETUP PDU and use the DTMF procedures to subsequently send the external subscriber 
number information, see subclause 14.5.1.2.5. 

NOTE 1 : The particular SSI address or addresses which identify the gateway or gateways are 
not defined by this part of this ETS. 

NOTE 2: Calls from external network subscribers to TETRA subscribers are supported in the air 
interface including presentation of the external user number, if available. This part of 
the ETS does not describe gateway functions, which are independent of the air 
interface protocol. 



14.5.1 .3 Call disconnection procedures 
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Figure 32: Individual call request-to-disconnect 
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1 4.5.1 .3.1 User initiated disconnection 

Either the calling or called user application may initiate a call disconnection at any state of a call. This shall 
be done by sending a TNCC-RELEASE request to the CC sub-entity. 

During call set-up phase until the U-SETUP PDU has been transmitted to the SwMI, a 
disconnection can be handled locally using a CANCEL request. Information regarding the local 
progress of the transmission of a PDU is received in REPORT indications. After a local cancellation 
the CC sub-entity shall stop timer T303 and return to state IDLE. 

On receipt of a TNCC-RELEASE request the CC sub-entity shall enter state CALL-DISCONNECT, 
send a U-DISCONNECT PDU, start timer T308 and stop all other T3xx timers. The progress of the 
disconnection PDU sending shall be reported back to CC with REPORT indications. 

After sending a U-DISCONNECT PDU the CC shall wait for a D-RELEASE PDU. When a D- 
RELEASE PDU or a REPORT indication with reason PDU transfer failed is received, or timer T308 
expires, the CC sub-entity shall clear the call identifier and shall return to state IDLE, issuing a 
TNCC-RELEASE confirm to the user application, see figure 32. The CC sub-entity shall send a 
CONFIGURE request to the lower layers to switch the U-Plane off. 

The SwMI should inform the other MS in the call of the call clearance either by a D-DISCONNECT PDU or 
by a D-RELEASE PDU, see subclause 14.5.1 .3.3. 

1 4.5.1 .3.2 Network initiated disconnection 

In the case where the SwMI cannot support a request for a call from the calling MS/LS, the SwMI should 
send a D-RELEASE PDU, containing the reason for disconnection, to the calling MS/LS. 

In the case where the SwMI can no longer support an established call, it should send D-RELEASE PDUs 
to the calling and called MS/LSs containing the reason for disconnection, and should subsequently release 
the call. 

Refer to subclause 14.5.1 .3.3 for the MS/LS actions. 

1 4.5.1 .3.3 Reception of disconnection request 

The BS may send a disconnection request at any phase of the call and the MS/LS shall react as follows: 

when the CC sub-entity receives a D-DISCONNECT PDU the CC shall respond by sending 
a U-RELEASE PDU; 

when the CC sub-entity receives a D-RELEASE PDU the CC shall not send any response; 

in both cases the CC shall inform the user application with a TNCC-RELEASE indication, clear the 
call identifier, stop ail T3xx timers and enter state IDLE, see figure 32. The CC sub-entity shall send 
a CONFIGURE request informing the lower layers to switch the U-Plane off. 

1 4.5.1 .3.4 Expiry of timers 

a) Timer T301 ; call set-up timer for called MS/LS 

Upon expiry of timer T301, CC shall send a TNCC-RELEASE indication primitive to the user 
application, send a U-DISCONNECT PDU and follow the procedures in subclause 14.5.1.3.1. The 
value of the disconnect cause element shall be set to "expiry of timer". 

b) Timer T302; call set-up timer for calling MS/LS 

Upon expiry of timer T302, CC shall send a TNCC-RELEASE indication primitive to the user 
application, send a U-DISCONNECT PDU and follow the procedures in subclause 14.5.1.3.1. The 
value of the disconnect cause element shall be set to "expiry of timer". 
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c) Timer T303; call initiated timer for calling MS/LS 

Upon expiry of timer T303, CC shall send a TNCC-RELEASE indication primitive to the user 
application, send a U-DISCONNECT PDU and follow the procedures in subclause 14.5.1.3.1. The 
value of the Disconnect Cause element shall be set to "expiry of timer''. 

d) Timer T306; call restoration timer for point-to-point calls 

Upon expiry of timer T306, CC shall return to state IDLE, and send a TNCC-RELEASE indication 
primitive to the user application. The value of the disconnect cause element shall be set to "expiry 
of timer", 

e) Timer T308; call disconnect timer 

Upon expiry of timer T308, CC shall return to state IDLE, send a TNCC-RELEASE confirm primitive 
to the user application and shall send a CANCEL request to the lower layers to cancel the sending 
of the U-DISCONNECT PDU. The value of the disconnect cause element shall be set to "expiry of 
timer". 

f) Timer T310; call length timer 

Upon expiry of timer T310, CC shall send a TNCC-RELEASE indication primitive to the user 
application, send a U-DISCONNECT PDU and follow the procedures in subclause 14.5.1.3.1. The 
value of the disconnect cause element shall be set to "expiry of timer". 

g) Timer T31 1 ; call transmission timer 

Upon expiry of timer T311, CC shall remain in state ACTIVE, send a TNCC-TX indication primitive 
to the user application and a U-TX-CEASED PDU to the peer entity. The CC shall send the 
U-TX-CEASED PDU with the stealing permission set to "immediate stealing" and stealing repeats 
flag set. 

A D-TX-CEASED PDU from the SwMI shall be expected. 

h) Timer T321 ; CC-SS retention timer 

The SwMI may delete the reference to the call ID and all information relating to that call ID. 
NOTE: Timer T321 is only applicable to the SwMI. 
14.5.1 .3.5 Colliding disconnection 

Disconnection collision can occur when both sides simultaneously send DISCONNECT PDUs specifying 
the same call identifier value. If a CC sub-entity receives a D-DISCONNECT PDU when CC has just 
issued a U-DISCONNECT PDU, the CC sub-entity shall discard the outgoing disconnection request and 
respond to the incoming D-DISCONNECT PDU as defined in subclause 14.5.1 .3.3. 

If the U-DISCONNECT PDU collides with a D-RELEASE PDU, the CC sub-entity shall release the call 
immediately as defined in subclause 14.5.1.3.3. 

In either case the CC shall send a CANCEL request to the lower layers to cancel the sending of the U- 
DISCONNECT PDU. 

1 4.5.1 .4 U-Plane switching 

The U-Plane switching procedure ensures that traffic/signalling synchronisation between CMCE and MAC 
is maintained during the lifetime of a call. The CC informs the MAC when it has permission to transmit 
traffic (i.e. TCH or STCH) and when to stop. The CC also informs the MAC when it may process received 
traffic (and when to stop). The latter procedure also assists the MAC to interpret when the received bit- 
stream on the assigned channel is TCH/STCH and when it is SCH. 
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The CC changes the U-plane operation in the MAC by issuing the CONFIGURE request primitive, 
indicating "Switch U-plane = On" or "Switch U-plane = Off", "Tx grant = true" or "Tx grant = false" and 
"simplex/duplex = simplex" or "simplex/duplex = duplex". There shall be only four valid combinations: 

1 ) Switch U-plane = On t Tx grant = true, simplex/duplex = simplex; 

MS/LS is authorised to transmit traffic; 

2) Switch U-plane = On, Tx grant = false, simplex/duplex = simplex; 

MS/LS is authorised to receive traffic; 

3) Switch U-plane = On, Tx grant = true, simplex/duplex = duplex; 

MS/LS is authorised to transmit and receive traffic; 

4) Switch U-plane = Off; 

withdraws previous authorisation to transmit and/or receive traffic. 

1 4.5.1 .4.1 End of call set-up phase 

When the CC in a MO call receives a D-CONNECT PDU, or when the CC in a MT call receives a 
D-CONNECT ACKNOWLEDGE PDU, it shall issue a CONFIGURE request primitive to the lower layers 
containing information about the call e.g. the type of traffic, the interleaving depth, the call identifier and 
whether the call is end-to-end encrypted. 

If the transmission grant element in the PDU is set to "transmission granted" then the CONFIGURE 
request shall contain the parameter value "Switch U-Plane = On" and "Tx grant = true" to indicate that the 
MAC has permission to transmit traffic. If the transmission grant element is set to "transmission granted to 
another user" then the CONFIGURE request shall contain the parameter value "Switch U-Plane = On" but 
shall contain "Tx grant = false" to indicate that the MAC should receive traffic. 

For the other values of the transmission grant element, the U-plane shall not be switched on. 

1 4.5.1 .4.2 During call maintenance phase 

a) Transmission granted 

When the CC receives a D-TX-GRANTED PDU, and if the transmission grant element is set to 
"transmission granted" or "transmission granted to another user", then the CC shall issue a 
CONFIGURE request containing the parameter value "Switch U-Plane = On" and indicating whether 
the MAC has permission to transmit traffic ("Tx grant = true" or "Tx grant = false" respectively). For 
the other values of the transmission grant element, the U-plane state shall not be changed. 

NOTE: Sometimes consecutive CONFIGURE requests issued to the lower layers will both 
contain the instruction to "Switch U-plane On" but will change the traffic transmit 
permission. 

b) Transmission ceased 

When CC receives a D-TX-CEASED PDU, or on receipt of a REPORT indication of either 
successful or unsuccessful transmission of a U-TX CEASED PDU, the CC shall issue a 
CONFIGURE request containing the parameter value "Switch U-Plane = Off". 

c) Temporary interruption 

When the CC receives a D-TX WAIT PDU, and if the U-plane is currently switched on for either 
transmission or reception, the CC shall issue a CONFIGURE request containing the parameter 
value "Switch U-plane = Off". 
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When the CC receives a D-TX CONTINUE PDU, and if the Continue element is set to "continue" 
and the U-plane was switched on at the time of receipt of the D-TX WAIT PDU, then the CC shall 
issue a CONFIGURE request containing the same parameter values as before the temporary 
interruption. Otherwise, the U-plane shall not be switched on. 

d) Stop for pre-emptive priority request 

When the CC receives a D-TX INTERRUPT PDU, and if the transmission grant element is set to 
"transmission granted to another user", the CC shall issue a CONFIGURE request containing the 
parameter value "Switch U-Plane = On" but shall contain "Tx grant = false" to indicate that the MAC 
should receive traffic (and no longer has permission to transmit traffic). For the other values of the 
transmission grant element, the CC shall issue a CONFIGURE request containing the parameter 
value "Switch U-Plane = Off". 

e) Call restoration 

When CC receives a BREAK indication indicating that a temporary break in the radio link has 
occurred, the CC shall issue a CONFIGURE request containing the parameter value 
"Switch U-Plane = Off". 

When CC receives a D-CALL-RESTORE PDU indicating that the call has now been restored after a 
temporary break in the radio link, and if the transmission grant element is set to "transmission 
granted" or "transmission granted to another user", then the CC shall issue a CONFIGURE request 
containing the parameter value "Switch U-Plane = On" and indicating whether the MS has 
permission to transmit traffic ("Tx grant = true" or "Tx grant = false" respectively). For the other 
values of the transmission grant element, the U-plane shall not be switched on. 

1 4.5.1 .4.3 Call disconnection phase 

When CC receives a D-RELEASE PDU or a D-DISCONNECT PDU, or on receipt of a REPORT indication 
of either successful or unsuccessful transmission of a U-DISCONNECT PDU, the CC shall issue a 
CONFIGURE request to the lower layers containing the parameter value "Switch U-Plane = Off". 

14.5.2 Group CC procedures 

The CC procedures handled by CC shall be applicable for circuit mode calls for both speech and data. 
The circuit mode speech and data group calls shall be set-up as point-to-multipoint calls. The specification 
below shall be applicable for the procedures that reside in the MS/LS. 

14.5.2.1 Call set-up procedures 

a) Normal group call 

The normal group call procedures provide support for one type of call set-up, where the MS is 
placed immediately into the call upon receipt of the D-SETUP PDU if the called user application can 
support the call and with immediate action being taken by the called user application. 

The set-up signalling procedures shall allow immediate communication to take place between the 
calling and called user applications without the necessity of having an alerting process and without 
an explicit response from the called user application stating that the user has answered. The call 
priority may affect whether the user application accepts the call or not. 

NOTE: The behaviour of the user application between the reception of the incoming set-up 
signalling and the acceptance/reject of the call is outside the scope of this ETS. 

The MS does not signal that acceptance or rejection to the BS. 
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Figure 33: Group call - set-up phase 



b) Acknowledged group call 



An acknowledged group call allows the SwMl to poll members of the called group during the call. The call 
may be through connected to the calling MS either before polling or after polling has taken place (see 
subclause 14.5.2.6). 
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Figure 34: Acknowledged group call - set-up phase 
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c) Broadcast call 

The call set-up procedure for broadcast call shall be the same as that for group call as shown in figure 33. 
However, in this case the called MSs shall not be able to subsequently request transmit permission. 

14.5.2.1.1 Incoming call 

Notification of the arrival of an incoming call to the CC sub-entity shall be made by the reception of a 
D-SETUP PDU which shall be delivered to the user application in a TNCC-SETUP indication via the 
TNCC-SAP. The CC shall enter state MT-CALL-SETUP. If the user application can support the call, it 
shall immediately return a TNCC-SETUP response. 

On reception of a TNCC-SETUP response the CC sub-entity shall enter state CALL ACTIVE and take the 
following actions, which are dependent upon the information contained within the PDU elements, see 
figure 33, right hand side: 

the call identifier shall be used as the reference to this call in subsequent PDUs for the duration of 
the call; 

when CC receives TNCC-SETUP response indicating that the called user application has accepted 
the incoming call, the CC sub-entity shall enter state CALL ACTIVE and start timer T310. The 
D-SETUP PDU shall contain an indication in the transmission grant element whether the MS/LS 
should switch to U-plane reception. If the D-SETUP PDU contains an indication that the MS/LS is 
allowed to request transmission permission it may follow the transmission control procedures 
described in subclause 14.5.2.2.1 a). The CC sub-entity shall send a CONFIGURE request for 
lower layer configuration; 

where the called user application is unable to accept the request for a certain target service, the call 
shall be rejected locally by issuing a TNCC-RELEASE request via the TNCC-SAP and the CC shall 
enter state IDLE. No negotiation with the BS shall be possible. 

14.5.2.1.2 Outgoing call 

A user application initiates call establishment by transferring a TNCC-SETUP request across the 
TNCC-SAP to the CC sub-entity. The TNCC-SETUP request shall be handled by a CC sub-entity that is in 
state IDLE. The CC shall select a PDU priority based on the requested access priority value as defined in 
subclause 14.5.6.2. The CC shall convert this request into a U-SETUP PDU and send it. The CC 
sub-entity shall then enter the MO-CALL-SETUP state and start timer T303, see figure 33 - left hand side. 

The TNCC-SETUP request shall include parameters that shall allow the user application to select a target 
. grade of service and a lowest acceptable grade of service. These shall allow the user application to e.g. 
accept a lower bit rate or interleaving depth for a circuit mode data call than that requested. The 
parameters shall be as defined in clause 1 1 . 

The following text describes the normal call set-up procedures: 

to indicate the progress of the transmission of the U-SETUP PDU the CC may receive one or more 
REPORT indications. If the CC receives a REPORT indication informing that the PDU transmission 
has failed, timer T303 shall be stopped, and the CC sub-entity shall inform the user application with 
a TNCC-RELEASE indication and return to state IDLE; 

the SwMI may respond to the reception of the U-SETUP PDU with a D-CALL PROCEEDING PDU. 
Upon reception of the D-CALL-PROCEEDING PDU, the CC shall inform the user application by 
issuing a TNCC-PROCEED indication, stop timer T303, and start timer T302; 

the D-CALL-PROCEEDING PDU shall contain a call identifier which shall be used as the reference 
to this call in subsequent PDUs for the duration of the call; 

on reception of a D-INFO PDU after reception of D-CALL PROCEEDING but before the call set-up 
is completed, the CC shall start timer T302 from the value indicated in the call time out, set-up 
phase element if that element is present; 
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if the call through connection is ready at the time when the D-CALL PROCEEDING PDU should 
have been sent, a D-CONNECT PDU should be sent instead. In this instance the D-CONNECT 
PDU shall allocate the call identifier; 

on receipt of a D-CONNECT PDU, the CC shall enter state CALL ACTIVE, and inform the user 
application with a TNCC-SETUP confirm, and stop timer T302 or T303 and start timer T310. The 
D-CONNECT PDU shall contain an indication as to whether the CC has been given permission to 
transmit. If transmission is not granted and the D-CONNECT PDU contains an indication that the 
MS/LS is allowed to request transmission permission it may follow the transmission control 
procedures defined in subclause 14.5.2.2.1. The CC sub-entity shall send a CONFIGURE request 
for lower layer configuration. If the CC has been given permission to transmit then it shall start timer 
T311; 

where the D-CONNECT or D-CALL PROCEEDING PDU indicates that the offered service is 
different to the one requested, and if the service offered is acceptable to the CC sub-entity 
according to the selected lowest service in the TNCC-SETUP request primitive, then the call shall 
continue. If it is not acceptable, then the CC shall disconnect the call using the procedures in 
subclause 14.5.2.3.1; 

the network may support other signalling from the calling MS to the SwMI and vice versa during the 
call set-up phase using U-INFO and D-INFO PDUs, for example, for the purpose of showing the 
progress of a call set-up. 

14.5.2.1.3 Colliding calls 

Call collisions can occur when both the SwMI and the MS/LS simultaneously send a D-SETUP PDU and a 
U-SETUP PDU. Two call set-ups are colliding when a D-SETUP PDU is received within the window where 
the CC waits for a call identifier from the SwMI after a U-SETUP PDU has been issued but before layer 2 
has indicated successful transmission of the PDU. The MS/LS shall be able to handle two types of call 
collision: 

if the colliding calls are call set-up attempts for the same group and the requested basic services 
are compatible and the calling MS/LS is a member of that group, then the SwMI should 
amalgamate the calls and the MS CC shall discard the outgoing call set-up attempt and accept the 
incoming call instead. The CC shall send a CANCEL request to the lower layers to cancel the 
sending of the U-SETUP PDU. 

if the call set-up attempts are not to the same group, then the MS shall either keep its call attempt 
or accept the incoming call as defined in subclause 14.5.2.1.1. In the latter case the MS shall first 
cancel its call set-up locally, if still possible, or otherwise send a U-DISCONNECT PDU for its own 
call set-up, refer subclause 14.5.2.3.1. 

If the SwMI has sent a layer 2 acknowledgement to a U-SETUP PDU then it should send further signalling 
to the CC as calling party i.e. a D-CALL PROCEEDING and/or D-CONNECT PDU (and/or D-RELEASE 
PDU). 

14.5.2.1 .4 Unsuccessful call set-up 

Unsuccessful call set-up shall refer specifically to those instances where a circuit mode connection was 
not successfully established. It shall not refer to call disconnection or call rejection. If a PDU is not 
responded to prior to the expiry of the corresponding timer, the procedure in subclause 14.5.2.3.5 shall 
apply. All timers available are listed in subclause 14.6. 

When CC receives a REPORT indication indicating that the lower layers have not been successful (failed 
transfer) in the sending of any of the call set-up PDUs, then the CC sub-entity shall return to state IDLE 
and inform the user application with a TNCC-RELEASE indication accompanied with a cause of the 
disconnection. 

14.5.2.1.5 Call rejection 

If the user application decides to reject the incoming call set-up request as defined in subclause 
14.5.2.1.1, it shall immediately transfer a TNCC-RELEASE request to the CC sub-entity. This request 
shall locally clear the call identifier. The CC sub-entity shall then change to state IDLE. 
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14.5.2.2 



Call maintenance procedures 



The call maintenance procedures shall only be applied when the MS/LS is in state CALL-ACTIVE. The 
main state CALL-ACTIVE can comprise several sub-states. 
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D-TX INTERRUPT is sent to the remaining members of the group upon permission 
award to the MS shown on the left hand side of this figure. 



Figure 35: Group call - request-to-transmit 



a) Request-to-transmit 



The SwMI shall fully control which MS/LS is allowed to transmit. To facilitate this, the MS/LS shall 
request permission to transmit, and permission shall be granted before the MS can begin circuit 
mode traffic permission. MS/LSs may request permission to transmit, if the SwMI allows it by a 
"transmission request permission" element even if another party is transmitting. In this case the 
SwMI should normally wait for that party to finish the transmission before granting the other user 
application. Pre-emptive priority requests are dealt with in subclause 14.5.2.2.1 f)- 

The SwMI normally gives the first permission to transmit to the calling MS/LS when a new call has 
been set-up. However, the calling user application may allow the called users to request permission 
to transmit first. The calling CC shall in that case set the "request to transmit" bit accordingly in the 
U-SETUP PDU. 
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When a user within a call wants to transmit, a TNCC-TX request shall be sent to CC via the 
TNCC-SAP. The CC shall send this request in a U-TX-DEMAND PDU. The TX-DEMAND Priority 
level should be set to low or high priority, unless this is a pre-emptive priority request, see 
subclause 14.5.2.2.1 0. see figure 35. 

The progress of the transmission of the U-TX DEMAND PDU shall be given locally to the CC in one 
or more REPORT indication primitives. If the CC receives a REPORT indication as a response to 
the sending of the U-TX DEMAND PDU informing that the PDU transmission has failed, the CC 
shall inform the user application by a TNCC-TX confirm primitive. 

If a user application wants to withdraw his request-to-transmit before it has been granted, a 
TNCC-TX request shall be sent from the user application to the TNCC-SAP. The CC shall send this 
request in a U-TX-CEASED PDU. The CC shall send the U-TX CEASED PDU with the stealing 
permission set to "immediate stealing" and stealing repeats flag set so that the permission to 
transmit will be released immediately if allocated. No CC protocol response shall be received from 
the SwMI for this message. 

b) Response to request-to-transmit 

During a call in progress and when the SwMI has decided which MS/LS shall be given permission 
to transmit, the SwMI shall send a D-TX GRANTED PDU as an individual message to the granted 
MS/LS. Upon reception of a D-TX GRANTED PDU indicating "transmission granted", the CC sub- 
entity shall send this information to the user application in a TNCC-TX confirm. The other MS/LSs 
involved in the call shall be informed with a D-TX GRANTED PDU addressed with the group 
address. That D-TX-GRANTED PDU shall indicate that permission to transmit has been granted to 
another user. The CC shall send this information to the user application in a TNCC-TX indication 
and shall remain in state CALL-ACTIVE, see figure 35. 

If the SwMI places the transmission request in a queue this shall be indicated to the MS/LS 
concerned using the "transmission request queued" parameter value in the D-TX-GRANTED PDU. 
If the SwMI rejects the transmission request this may be indicated to the MS/LS concerned using 
the "transmission not granted" parameter value in the D-TX GRANTED PDU. In either case, the 
MS/LSs concerned shall remain in state CALL-ACTIVE. 

Upon reception of a D-TX-GRANTED PDU indicating "transmission granted" or "transmission 
granted to another user", the CC sub-entity shall issue a CONFIGURE request primitive. The 
primitive shall carry as a parameter whether the transmit permission has been granted to this CC 
sub-entity or to another CC sub-entity, and to switch the U-Plane on. The MS/LS given permission 
to transmit shall start timer T311. If the D-TX GRANTED PDU indicates "transmission granted to 
another user" and contains the LS/MS's own address as the transmitting party address then that 
MS/LS should not switch to U-plane reception. However it shall not switch to U-piane transmission 
until it receives a D-TX GRANTED PDU indicating "transmission granted". 

Upon reception of a D-TX GRANTED PDU indicating "transmission granted to another user", and if 
the CC sub-entity has issued a U-TX DEMAND PDU to the lower layers and has not yet received a 
REPORT indication indicating successful or unsuccessful transmission, then the CC sub-entity shall 
send a CANCEL request primitive to the lower layers to cancel transmission (and re-transmissions) 
of that PDU. 

NOTE 1 : . The above procedure may sometimes stop re-transmissions by the awarded MS/LS as 
well as re-transmissions by any other MS/LSs that are requesting transmit permission. 

NOTE 2: If the SwMI queues any other transmission requests that it received then it should, at a 
convenient time, send D-TX GRANTED PDUs containing the "transmit request 
queued" parameter value to the MS/LSs concerned. For transmission requests that 
are neither granted nor queued, and if the user application still wishes to transmit, then 
it has to send another TNCC-TX request to the CC. 

After reception of a D-TX GRANTED PDU indicating "transmission granted", and while it still has 
permission to transmit, the CC shall ignore any group addressed D-TX GRANTED or 
D-TX INTERRUPT PDUs it may receive (and any layer 2 channel allocation received with those 
PDUs). 
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If the CC sends a U-TX-DEMAND PDU whilst another MS is transmitting, the SwMI should normally 
wait for that party to finish the transmission (identified by the receipt of a U-TX-CEASED PDU), 
before granting transmission permission to the other user application. On receipt of the 
U-TX DEMAND PDU, the SwMI may send a D-TX GRANTED PDU indicating whether the 
request-to-transmit is queued or rejected. Pre-emptive priority requests are dealt with in 
subclause 14.5.2.2.1 f). 

c) Permission to transmit withdrawn 

The SwMI may decide to interrupt transmission when resources are required for another call or 
when the SwMI requires that the call should temporarily pause. In this case the SwMI should send a 
D-TX-WAIT PDU to all MS/LSs in that call (permitting or denying transmission requests according 
to the "transmission request permission" element). On reception of the D-TX-WAIT PDU the CC 
sub-entity shall send a TNCC-TX indication to the user application indicating that the transmission 
is waiting. The CC shall stop timer T31 1 , if activated, enter state WAIT, and send a CONFIGURE to 
switch the U-Plane off. The CC shall accept any layer 2 channel allocation and await further 
instructions on the channel that they have been directed to. 

If a request-to-transmit has been queued at the time when the D-TX WAIT PDU is received, the MS 
shall be allowed to withdraw its request-to-transmit by means of the U-TX-CEASED PDU as 
described in subclause 14.5.2.2.1 e). 

A group-addressed D-TX WAIT PDU shall apply to all the MS/LSs in the call (including the 
transmitting MS/LS). Optionally, the D-TX WAIT PDU may also be sent individually addressed to 
the transmitting MS/LS enabling the SwMI to obtain a layer 2 acknowledgement from that MS/LS. 

d) Permission to continue with withdrawn call 

There are three cases as follows: 

1) if no MS/LS was granted transmission at the time when the SwMI sent the D-TX WAIT PDU, 
or if an MS/LS was granted transmission at the time of the D-TX WAIT PDU but the SwMI 
does not wish that transmission to continue, then a D-TX-CONTINUE PDU with the continue 
element set to "not continue" should be sent as a group message to all MS/LSs in the group. 
The CC shall accept any layer 2 channel allocation. All CC sub-entities shall return to state 
CALL-ACTIVE but the U-plane shall not be switched on and the MS/LS shall assume that any 
previous transmission permission no longer applies. If the D-TX CONTINUE PDU contains 
an indication that the MS/LS is allowed to request transmission permission, it may follow the 
transmission control procedures described in subclause 14.5.2.2.1 a). 

2) If there was one MS/LS granted transmission at the time when the SwMI sent the D-TX- 
WAIT PDU, and if the SwMI wishes that transmission to continue, then a D-TX-CONTINUE 
PDU with the Continue element set to "continue 0 should be sent as a group message to the 
group and the CC shall accept any layer 2 channel allocation. This message shall give the 
earlier granted MS/LS permission to continue transmission. The MS granted permission to 
transmit shall start timer T311. All CC sub-entities shall return to state CALL ACTIVE and 
shall send a CONFIGURE request to the lower layers to switch the U-plane on. 

A group-addressed D-TX CONTINUE PDU shall apply to all the MS/LSs in the call (including 
the awarded MS/LS). Optionally, the D-TX CONTINUE PDU may also be sent individually 
addressed to the awarded MS/LS enabling the SwMI to obtain a layer 2 acknowledgement 
from that MS/LS. 

3) If a MS/LS has requested permission to transmit during the period when the transmission 
was withdrawn, the SwMI should first send a D-TX-CONTINUE as a group message with the 
Continue element set to "not continue". A D-TX GRANTED should then be sent as an 
individual message to the granted MS/LS and as a group message to the rest of the group 
allocating transmission permission as appropriate. 

An MS/LS may fail to receive the D-TX CONTINUE PDU. Therefore, if the MS/LS is in state WAIT 
and it receives a D-TX GRANTED PDU, it shall behave as if it had previously received a 
D-TX CONTINUE PDU with the continue element set to "not continue". It shall then obey the 
instruction in the D-TX GRANTED PDU. 
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e) End of Transmission 

At the end of a transmission the user application shall send a TNCC-TX request to the TNCC-SAP 
indicating ceased transmission. The CC sub-entity shall send this information in a U-TX-CEASED 
PDU and stop timer T31 1 . The CC shall send the U-TX CEASED PDU with the stealing permission 
set to "immediate stealing" and the stealing repeats flag set. Upon reception of the U-TX-CEASED 
PDU, the SwMI normally sends a D-TX-CEASED PDU to the group informing the group members 
that the transmission has now ceased. 

Upon reception of a D-TX-CEASED PDU the CC shall send this information to the user application 
in a TNCC-TX indication (transmission ceased) and the CC shall send a CONFIGURE request to 
the lower layers to switch the U-Plane off, see figure 35. 

Also, if the CC that is sending the U-TX CEASED PDU receives a REPORT indication of either 
successful or unsuccessful transmission of that PDU by the lower layers, then it shall behave as if it 
had received a D-TX CEASED PDU i.e. it shall send a TNCC-TX indication (transmission ceased) 
to the user application and shall send a CONFIGURE request to the lower layers to switch the U- 
Plane off. If a D-TX CEASED PDU is received but no REPORT indication of successful 
transmission of the U-TX CEASED PDU then the CC shall send a CANCEL request primitive to the 
lower layers to stop re-transmissions of the U-TX CEASED PDU. 

NOTE 3: The requirement for the CC to cancel re-transmissions may apply if the SwMI sends 
only a group-addressed D-TX CEASED PDU and the transmitting MS/LS does not 
receive a layer 2 acknowledgement. 

If there was a request for transmission already queued in the SwMI when the U-TX CEASED PDU 
was received, the SwMI may send a D-TX GRANTED PDU as an individual message to the granted 
MS/LS and another D-TX GRANTED PDU as a group message to the rest of the group as 
described in subclause 14.5.2.2.1. b) ( without sending an explicit D-TX CEASED PDU. However, 
the SwMI should first send at least a layer 2 acknowledgement to the MS/LS that sent the 
U-TX CEASED PDU so that the MS/LS can stop its U-plane transmission and start accepting group 
addressed D-TX GRANTED PDUs. 

f) Stop-transmission order 

If a MS/LS wishes to interrupt the transmitting MS with a pre-emptive priority request, it shall send a 
U-TX-DEMAND indicating the level of priority in the TX demand priority" element. The SwMI may 
send a D-TX-INTERRUPT PDU to the MS/LS which currently has permission to transmit. Upon 
reception of an individually addressed D-TX-INTERRUPT PDU the CC sub-entity shall remain in 
state CALL-ACTIVE, and shall stop timer T311. The CC shall send information to the user 
application in a TNCC-TX indication primitive indicating transmission interrupt and the CC sub-entity 
shall send a CONFIGURE request to the lower layers to switch the U-Plane accordingly (see 
subclause 14.5.2.4). 

The SwMI should send a D-TX-INTERRUPT PDU as a group message to the rest of the group 
indicating that the permission to transmit has been (or will be) allocated to another user, see 
figure 35. Upon reception of the D-TX-INTERRUPT PDU the CC sub-entity shall remain in state 
CALL ACTIVE and shall send a TNCC-TX indication primitive to the user application indicating 
transmission interrupt. The SwMI should then send a D-TX GRANTED PDU as an individual 
message to the MS/LS that requested the priority transmission. 

Normally the D-TX-INTERRUPT PDU indicates that transmission is granted to another user and 
then the MS/LS shall switch to (or remain in) U-plane reception. Otherwise, if there is a delay before 
the pre-emptive priority transmission, the SwMI may indicate "transmission not granted" in the 
D-TX-INTERRUPT PDU. Then the MS/LS shall switch the U-plane off and wait for a 
D-TX-GRANTED PDU. 
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g) Call continuation 

The SwMI may decide to change the call time-out time by sending a D-INFO PDU with a new T310 
value. Upon reception of the D-INFO PDU containing the "call time-out" element, T310 shall be 
started using the defined value. 

The SwMI may also choose to reset the call time-out time and start it again using the current 
defined value. Upon reception of the D-INFO PDU with the "reset call time-out timer" element 
indicating that T310 shall be reset, T310 shall be started using the value defined earlier. 

In either case, the Timer value shall be sent further on to the application in a TNCC-NOTIFY 
indication primitive. 

14.5.2.2.2 Call status information procedures 

The D-INFO PDU can be used for carrying call status messages from SwMI to the MS/LS. When a 
D-INFO PDU is received, depending on the notification, the following actions shall be taken by CC: 

a) call in queue: 

when the SwMI has put a call into a queue, if the D-INFO PDU contains a value for the call 
time-out, set-up phase, the CC shall start timer T302 using that value. The CC shall send the 
information further on to the application in a TNCC-NOTIFY indication primitive. If the call is 
queued at call set-up time the D-INFO PDU should be preceded by a 
D-CALL-PROCEEDING PDU; 

b) call is proceeding: 

this may be sent to the calling user application during the call set-up phase to indicate that 
the call set-up time will be longer than for a normal call set-up. The information that the call 
time-out, set-up phase value shall be changed is made available to the CC sub-entity in the 
D-INFO PDU. The CC shall start T302 using the new timer value. The CC shall send the 
information further on to the application in a TNCC-NOTIFY indication primitive. 

14.5.2.2.3 Call modification procedures 

The MS/LS service user may modify the service of an existing call. To initiate a modification the user 
application shall issue aTNCC-MODIFY request primitive and the CC sub-entity shall send aU-INFO 
PDU and wait for a D-INFO PDU from the SwMI before changing any of the current service parameters. 
The SwMI should not send D-INFO to modify a service while an ongoing U-Plane transmission is in 
progress. 

When a service has been changed by the SwMI, the SwMI should indicate this to the calling and called 
parties by issuing the D-INFO PDU. Upon reception of a D-INFO PDU indicating an acceptable service 
modification the CC sub-entity shall send it to the application in a TNCC-MODIFY indication primitive, and 
the CC sub-entity shall send a CONFIGURE request primitive for lower layer configuration. 

The service may be changed between any combination of one or more of the following: 

a clear call may be changed to an encrypted call; or 

an encrypted call may be changed to a clear call; 

a 4-slots-per-frame call may be changed to a 1 -slot, 2-slot or 3-siot call; 

a 3-siot call may be changed to a 1 -slot or 2-slot call; 

a 2-slot call may be changed to a 1 -slot call; 

a circuit mode type (TCH/S, TCH/7.2, TCH/4.8 or TCH/2.4) may be changed to a different circuit 
mode type. 
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The encryption state of each transmission, defined using D-TX GRANTED, can be set independently by 
the encryption control element in the U-TX-DEMAND PDU. It is also possible to change between the 
circuit mode speech teleservice and a circuit mode unprotected (speech, encrypted) bearer service. The 
SwMI should not change the requested encryption state in the responding D-TX-G RANTED PDU from 
that requested in the U-TX DEMAND PDU. 

If the MS/LS cannot support a new service combination indicated by D-INFO, D-TX GRANTED or 
D-TX-INTERRUPT, the user application or the CC as appropriate shall disconnect or leave the call, refer 
to subclause 14.5.2.3. The U-DISCONNECT PDU shall contain disconnection cause "requested service 
not available* 1 . 



14.5.2.2.4 
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Figure 36: Group call - successful call restoration 
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Figure 37: Group call - unsuccessful call restoration 



Call restoration of a group call shall only take place in the CC sub-entity when the CC has entered state 
CALL-ACTIVE. The CC sub-entity should keep information on whether it is active in a group call or an 
individual call. 

When the CC receives a BREAK indication, the CC shall switch the U-Plane off as described in 
subclause 14.5.2.4 and shall remain in state CALL-ACTIVE. 

If the CC receives a RESUME indication indicating that the C-Plane may now be used again, it shall issue 
a U-CALL-RESTORE PDU containing the GSSI and the call identifier of the call which CC wants to 
restore. The CC shall start Timer T307 and wait for a D-CALL-RESTORE PDU. 
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When the CC receives a D-CALL-RESTORE PDU, timer T307 shall be stopped and the call shall be 
resumed with the new parameters, see figure 36. If appropriate the CC shall issue a CONFIGURE request 
to switch the U-Plane on using the procedure in subclause 14.5.2.4. 

If the call cannot be restored the CC shall receive a REOPEN indication primitive indicating that the call is 
lost. 

Upon reception of REOPEN indication or on expiry of timer T307, the CC shall then stop all T3xx timers, 
clear the call identifier and temporary group address if applicable, and return to state IDLE and it shall 
send a TNCC-RELEASE indication to the user application with the cause for disconnection, see figure 37. 

If there is more than one circuit mode call active at the time when the MLE-BREAK indication was 
received, each call shall be restored separately and hence U-CALL RESTORE and D-CALL RESTORE 
PDUs shall be exchanged one by one for each call. 

14.5.2.2.5 DTMF procedures 

When a user application requires to transfer DTMF digits to other user applications during a circuit mode 
call, it shall issue a TNCC-DTMF request primitive to the CC entity. CC shall send this request as a 
U-INFO PDU with the DTMF digits encoded as DTMF parameter values. The SwMI should then forward 
the DTMF digits to the group in a D-INFO PDU. 

On the reception of a D-INFO PDU the CC shall forward the DTMF digits to the user application in a 
TNCC-DTMF indication. 

14.5.2.2.6 Temporary address handling procedures 

There are different scenarios when a new temporary group address shall be recognised by the MS(s) 
during the rest of a call: 

1 ) when an individual user is included into an ongoing individual call, the call shall be converted to a 
group call and a temporary group number shall be assigned by the SwMI to all the individuals in that 
call; 

2) when an individual user is included into a group call, the group address of the including group shall 
be temporarily valid for that individual; 

3) when a group is included into an individual call, the members of the individual call shall be 
temporary members of the group and the address of the included group shall be temporarily valid 
for both individuals; 

4) when a group is included into another group call, the included group shall be temporarily assigned 
to the group address of the including group; 

5) when an individual user makes a call to a group which he is not a member of, that group number 
shall be recognised during the rest of the call for that calling subscriber. 

The information regarding the new temporary group address shall be sent to the subscribers either in a 
D-CONNECT or in a D-INFO PDU. 

Scenario 1: individually addressed D-INFO PDUs shall be sent to all individual users with the modify 
element indicating the change from individual to group call and with the temporary address element giving 
the new temporary group address. 

Scenario 2: individually addressed D-INFO PDU shall be sent to the included individual user with the 
modify element indicating the change from individual to group call and with the temporary address 
element giving the new temporary group address. 

Scenario 3: individually addressed D-INFO PDUs shall be sent to the including individual subscribers with 
the modify element indicating the change from individual to group call and with the temporary address 
element giving the included group address. 
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Scenario 4: group addressed D-INFO PDUs shall be sent down to the included group members with the 
temporary address element giving the new temporary group address. 

Scenario 5: the individually addressed D-CONNECT PDU to the calling subscriber may contain the 
temporary address element with the address of the called group. If the MS calls a group that it is not a 
member of, and if the D-CONNECT PDU does not contain the temporary address element, then the MS 
shall implicitly assume temporary membership of the called group address, for the duration of the call. 
This temporary membership shall apply only after receipt of the D-CONNECT PDU. 

In all cases the CC sub-entity shall send a CONFIGURE request informing the lower layers of the new 
temporary address and if required the change of basic service from individual to group call. 

When the call is then released, the CC sub-entity shall send a CONFIGURE request informing the lower 
layers that the temporary group address is not longer valid (see subclause 14.5.2.3). 



14.5.2.2.7 



Calls to and from external subscribers 



An external subscriber can call TETRA group numbers. The signalling needed between an external 
subscriber and a gateway is outside the scope of this ETS. The signalling between the SwMI and the 
called group is the same as that for a mobile originated group call. 
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Figure 38: Group call - request-to-disconnect 
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1 4.5.2.3.1 User initiated disconnection 

A user application may initiate call disconnection at any state of a call by sending a TNCC-RELEASE 
request to the CC sub-entity. Only the call owner may initiate call disconnection. The user, whether he is 
call owner or not, may also leave a call without disconnecting it. In that case there shall not be any 
disconnection related signalling from the MS to the SwMI. The disconnect type parameter in the 
TNCC-RELEASE request indicates whether the CC should disconnect the call or leave the call without 
disconnection. 

NOTE: The calling MS/LS is informed whether it is the call owner by the call ownership 
element in the D-CONNECT PDU. Any other MS/LS may be assigned call ownership 
by the D-INFO PDU. 

The following procedures shall apply to the user application that is designated as the call owner, figure 38 
refers: 

during call set-up phase until U-SETUP PDU has been transmitted to the SwMI, a disconnection 
can be handled locally using a CANCEL request. Information regarding the local progress of the 
transmission of a PDU is received in REPORT indications. After a local cancellation the CC 
sub-entity shall stop timer T303 and shall return to state IDLE; 

on receipt of a TNCC-RELEASE request in the CC sub-entity from the user application requesting 
call disconnection, the CC shall send a U-DISCONNECT PDU, start timer T308 and enter state 
CALL-DISCONNECT. All other T3xx Timers shall be stopped. The progress of the disconnection 
shall be reported to the CC with REPORT indications; 

if a U-DISCONNECT is issued, CC shall await a D-RELEASE PDU. When a D-RELEASE PDU or a 
REPORT indication with reason PDU transfer failed is received, or timer T308 expires, the CC 
sub-entity shall clear the call identifier, stop timer T308 and return to state IDLE, issuing a 
TNCC-RELEASE confirm to the user application. The CC sub-entity shall send a CONFIGURE 
request to the lower layers to clear the temporary group address and to switch the U-Plane off. 

The SwMI should inform the other MS/LSs in the call of the call clearance using a D-RELEASE PDU (see 
subclause 14.5.2.3.3 for MS/LS actions). 

If a group participant wishes to leave the group call, without disconnecting the call, the user application 
shall issue a TNCC-RELEASE request with disconnect type parameter equal to "leave call without 
disconnection": 

if the user wishes to leave the call without disconnection, the CC sub-entity shall clear the call 
identifier, stop all T3xx Timers and return to state IDLE, see figure 39. The CC sub-entity shall send 
a CONFIGURE request to the lower layers to clear the temporary group address and to switch the 
U-Plane off. 

14.5.2.3.2 Network initiated disconnection 

In the case where the SwMI cannot support a request for a call from the calling MS/LS, the SwMI shall 
send a D-RELEASE PDU containing the reason for disconnection, to the calling MS/LS. 

In the case where the SwMI can no longer support an established call, the SwMI should send a 
D-RELEASE PDU to all the MS/LSs in the group containing the reason for disconnection, and 
subsequently release the call. 

The MS/LS actions are defined in subclause 14.5.2.3.3. 

1 4.5.2.3.3 Reception of disconnection request 

The BS may send a disconnection request at any phase of the call and the MS/LS shall react as follows: 

when the CC sub-entity receives a D-RELEASE PDU the CC shall not send any response; 

the CC shall inform the user application with a TNCC-RELEASE indication, clear the call identifier, 
stop all T3xx timers and enter state IDLE, refer figure 38. The CC sub-entity shall send 
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a CONFIGURE request to the lower layer, to clear the temporary group address, if applicable, and 
to switch the U-Plane off. 

14.5.2.3.4 Colliding disconnection 

If the CC entity receives a D-RELEASE PDU when CC has just sent a U-DISCONNECT PDU, the CC 
sub-entity shall release the call immediately as defined in 14.5.2.3.3. In addition, the CC shall issue a 
CANCEL request to the lower layers to cancel any ongoing re-transmission of the U-DISCONNECT PDU. 

1 4.5.2.3.5 Expiry of timers 

a) Timer T302: call set-up timer for calling MS/LS. 

Upon expiry of timer T302, CC shall send a TNCC-RELEASE indication primitive to the user 
application, send a U-DISCONNECT PDU, and follow the procedures in subclause 14.5.2.3.1. The 
value of the disconnect cause element shall be set to "expiry of timer". 

b) Timer T303: call initiated timer for calling MS/LS. 

Upon expiry of timer T303, CC shall send a TNCC-RELEASE indication primitive to the user 
application, send a U-DISCONNECT PDU, and follow the procedures in subclause 14.5.2.3.1. The 
value of the disconnect cause element shall be set to "expiry of timer". 

c) Timer T307: call restoration timer for point-to-multipoint calls. 

Upon expiry of timer T307, CC shall apply procedures described in subclause 14.5.2.2.4. The value 
of the disconnect cause element shall be set to "expiry of timer". 

d) Timer T308: call disconnect timer. 

Upon expiry of timer T308, CC shall return to state IDLE, send a TNCC-RELEASE confirm primitive 
to the user application and shall send a CANCEL request to the lower layers to cancel the sending 
of the U-DISCONNECT PDU. The value of the disconnect cause element shall be set to "expiry of 
timer". 

e) Timer T310: call length timer. 

Upon expiry of timer T310, if the MS/LS is the call owner, the CC shall send a TNCC-RELEASE 
indication primitive to the user application, send a U-DISCONNECT PDU and follow the procedures 
in subclause 14.5.2.3.1 . The value of the disconnect cause element shall be set to "expiry of timer". 

If the MS/LS is not the call owner, CC shall return to state IDLE, and shall send a TNCC-RELEASE 
indication primitive to the user application and a CONFIGURE request to the lower layers. The 
value of the disconnect cause element shall be set to "expiry of timer". 

f) Timer T31 1 : call transmission timer. 

Upon expiry of timer T311, CC shall remain in state ACTIVE, shall send a TNCC-TX indication 
primitive to the user application and a U-TX-CEASED PDU to the peer entity. 

A D-TX-CEASED indication from the SwMI shall be expected. 

g) Timer T321 : CC-SS retention timer. 

The SwMI may delete the reference to the call ID and all information relating to that call ID. 
NOTE: Timer T321 is only applicable to the SwMI. 
1 4.5.2.4 U-Plane switching 

The U-Plane switching procedure ensures that traffic/signalling synchronisation between the CMCE and 
the MAC shall be maintained during the lifetime of a call. The CC informs the MAC when it has permission 
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to transmit traffic (i.e. TCH or STCH) and when to stop. The CC also informs the MAC when it may 
process received traffic (and when to stop). The latter procedure also assists the MAC to interpret when 
the received bit-stream on the assigned channel is TCH/STCH and when it is SCH. 

The CC changes the U-plane operation in the MAC by issuing the CONFIGURE request primitive, 
indicating "Switch U-plane = On" or "Switch U-plane = Off", Tx grant = true" or Tx grant = false" and 
"Simplex/duplex = simplex". There shall be only three valid combinations. 

1 ) Switch U-plane = On, Tx grant = true, Simplex/duplex = simplex; 

MS/LS is authorised to transmit traffic; 

2) Switch U-plane = On, Tx grant = false, Simplex/duplex = simplex; 

MS/LS is authorised to receive traffic; 

3) Switch U-plane = Off; 

withdraws previous authorisation to transmit and/or receive traffic. 

14.5.2.4.1 End of call set-up phase 

When the CC in a MO call receives a D-CONNECT PDU or when the CC in a MT call receives a 
D-SETUP PDU, it shall issue a CONFIGURE request primitive to the lower layers containing information 
about the call e.g. the type of traffic, the interleaving depth, the call identifier and whether the call is end- 
to-end encrypted. 

If the transmission grant element in the D-CONNECT PDU is set to "transmission granted" then the 
CONFIGURE request shall contain the parameter value "Switch U-Plane = On" and "Tx grant = true" to 
indicate that the MAC has permission to transmit traffic. If the transmission grant element is set to 
"transmission granted to another user" then the CONFIGURE request shall contain the parameter value 
"Switch U-Plane = On" but shall contain "Tx grant = false" to indicate that the MAC should receive traffic. 
For the other values of the transmission grant element, the U-plane shall not be switched on. 

If the transmission grant element in the D-SETUP PDU is set to "transmission granted to another user" 
then the CONFIGURE request shall contain the parameter value "Switch U-Plane = On" but shall contain 
"Tx grant = false" to indicate that the MAC should receive traffic. For the other values of the transmission 
grant element, the U-plane shall not be switched on. 

The only valid values of the transmission grant element in a group-addressed PDU shall be "transmission 
granted to another user" and "transmission not granted". 

1 4.5.2.4.2 During call maintenance phase 

a) Transmission granted: 

when the CC does not have permission to transmit, and if it receives a D-TX GRANTED PDU 
with the transmission grant element set to "transmission granted" or "transmission granted to 
another user", then the CC shall send a CONFIGURE request containing the parameter 
"Switch U-Plane = On" and indicating whether the MAC has permission to transmit traffic 
("Tx grant = true" or "Tx grant = false" respectively). For the other values of the transmission 
grant element, the U-plane state shall not be changed; 

while the CC has permission to transmit, it shall ignore group addressed D-TX GRANTED 
PDUs (see subclause 14.5.2.2.1 b)). 

b) Transmission ceased: 

when the CC receives a D-TX CEASED PDU or on receipt of a REPORT indication of either 
successful or unsuccessful transmission of a U-TX CEASED PDU, the CC shall issue a 
CONFIGURE request containing the parameter value "Switch U-Plane = Off". 
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c) Temporary interruption: 

when the CC receives a D-TX WAIT PDU, and if the U-plane is currently switched on for 
either transmission or reception, the CC shall issue a CONFIGURE request containing the 
parameter value "Switch U-plane = Off"; 

when the CC receives a D-TX CONTINUE PDU then: 

if the continue element is set to -continue*' and the MS/LS had permission to transmit 
traffic at the time of receipt of the D-TX WAIT PDU, then the CC shall issue a 
CONFIGURE request containing the parameter values "Switch U-Plane = On" and 
"Tx grant = true"; 

if the continue element is set to "continue" and the MS/LS did not have permission to 
transmit traffic at the time of receipt of the D-TX WAIT PDU, then the CC shall issue a 
CONFIGURE request containing the parameter value "Switch U-Plane = On" but 
containing "Tx grant = false"; 

if the Continue element is set to "not continue" then the U-plane shall not be switched on. 

d) Pre-emptive priority request: 

when the CC receives a D-TX INTERRUPT PDU, and if the transmission grant element is set 
to "transmission granted to another user", then the CC shall issue a CONFIGURE request 
containing the parameter value "Switch U-Plane = On" but containing "Tx grant = false" to 
indicate that the MAC should receive traffic. For the other values of the transmission grant 
element, the CC shall issue a CONFIGURE request containing the parameter value "Switch 
U-Plane = Off"; 

while the CC has permission to transmit, it shall ignore group addressed D-TX INTERRUPT 
PDUs. 

e) Call restoration: 

when CC receives a BREAK indication indicating that a temporary break in the radio link has 
occurred, the CC shall issue a CONFIGURE request containing the parameter value "Switch 
U-Plane = Off"; 

when CC receives a D-CALL-RESTORE PDU indicating that the call has now been restored 
after a temporary break in the radio link, and if the transmission grant element is set to 
"transmission granted" or "transmission granted to another user", then the CC shall issue a 
CONFIGURE request containing the parameter value "Switch U-Plane = On" and indicating 
whether the MS has permission to transmit traffic ("Tx grant = true" or "Tx grant = false" 
respectively). For the other values of the transmission grant element, the U-plane shall not be 
switched on. 

1 4.5.2.4.3 Call disconnection phase 

When the CC receives a D-RELEASE PDU, or if it receives a REPORT indication of either successful or 
unsuccessful transmission of a U-DISCONNECT PDU, or if it receives a TNCC-RELEASE request 
primitive from the user application indicating that the user wishes to leave the call (without disconnecting 
the call), then the CC shall issue a CONFIGURE request to the lower layers containing the parameter 
value "Switch U-Plane = Off". 

14.5.2.5 Acceptance of group-addressed channel allocation 

As described in subclause 14.5.2.1.1, it is optional whether the MS accepts an incoming group call. 
Therefore, when the MAC receives a channel allocation addressed to a group that the MS belongs to, it 
refers to the higher layers for instruction about whether to accept the channel allocation. 
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The lower layers indicate that instruction is required by setting the "channel change response required" 
parameter to "true". This parameter is passed (via LLC, MLE and PC) to CC along with the PDU. If the CC 
decides to accept the channel allocation then it shall immediately return a CONFIGURE request primitive 
including the parameter "channel change accepted". The CC shall decide whether or not to accept the 
channel allocation by applying the following rules: 

if the PDU is a D-SETUP PDU then: 

if the MS is not currently attempting to call this group then the CC shall accept the channel 
change if the user application accepts the incoming call using TNCC-SETUP response; 

if the MS is currently attempting to call this group, and has not received a REPORT indication 
of successful transmission of the U-SETUP PDU from the lower layers, then: 

if it is requesting a "basic service information" compatible with that in the D-SETUP 
PDU then it shall accept the channel change and shall send a CANCEL request 
primitive to the lower layers to stop re-transmissions of the U-SETUP PDU; 

if it is requesting a "basic service information" not compatible with that in the D-SETUP 
PDU then it shall accept the channel change if the user application accepts the 
incoming call using TNCC-SETUP response; 

if the MS is attempting to call this group and has received a REPORT indication of successful 
transmission of the U-SETUP PDU by the LLC then it shall not accept the channel change 
but shall wait on the current channel for further signalling: a D-CALL PROCEEDING and/or 
D-CONNECT PDU (and/or D-RELEASE PDU); 

if the PDU relates to an ongoing call (i.e. if the call identifier in the received PDU is the call identifier 
of any current call that the MS is active in) and if the CC accepts the received PDU then the CC 
shall accept the channel change. 

NOTE: The MS should not accept a group addressed channel allocation if it would thereby fail 
to receive an ongoing individual signalling exchange, individual advanced link or 
individual circuit mode call on the current channel(s). 

14.5.2.6 Acknowledged group call procedures 

The MS/LS procedures for handling of an acknowledged group call shall be in accordance with the 
procedures described for a normal group call in subclauses 14.5.2.1 to 14.5.2.5 with the following 
additions, which for the SwMI side are informative. 

The SwMI should poll the individuals within the called group on the traffic channel after call set-up. 

It is an operator option defined in the SwMI if the call should proceed immediately by giving the calling 
user permission to transmit before, during or after the called members of the group have been polled on 
the traffic channel. 

The SwMI may optionally use one of the following criteria for giving the calling user permission to transmit: 

the D-SETUP PDU has been sent to the called users and the polling will take place in parallel with 
the ongoing call; 

a certain number of users have responded to the poll; 

all users have been polled. 

As a poll request, all MS/LS shall be prepared to receive a D-INFO PDU during the call from the SwMI. 

Upon reception of a D-INFO PDU indicating a poll request the CC entity shall send this information further 
on to the user in a TNCC-NOTIFY and send a U-INFO PDU to the SwMI. The U-INFO shall be sent 
immediately by the CC on receipt of the poll request, see figure 34. 
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As an operator option the SwMI may disconnect the call after a certain time if insufficient number of 
members are present, before the permission to transmit is given. 

It is a SwMI option how and when to inform the calling user or any other user the result of the polling. An 
MS/LS shall, during the call set-up phase or during an ongoing call, be prepared to receive one or more 
D-INFO PDU with the following alternative poll results: 

percentage of responding number of group members; 

number of responding group members; 

list of identities of the responding group members. 
The CC shall send the poll result in the D-INFO PDU to the user application in a TNCC NOTIFY indication. 
1 4.5.3 Traffic channel assignment procedures 

This subclause describes procedures which shall be applicable only to the SwMI. Depending on the traffic 
case, alternative methods for traffic channel assignment can be used as presented in table 56. 



Table 56: Traffic channel assignment 



TRAFFIC CASE 


Early traffic 

channel 
assignment 


Medium traffic 
channel 
assignment 


Late traffic 

channel 
assignment 


Message trunked system; 
Individual call; 
On/Off hook signalling; 


Yes 


Yes 


Yes 


Message trunked system; 

Individual call; 

Direct set-up signalling; 


Yes 


No 


Yes 


Transmission trunked system; 
Individual call; 
On/Off hook signalling; 


No 


No 


Yes 


Transmission trunked system; 

Individual call; 

Direct set-up signalling; 


No 


No 


Yes 


Quasi-transmission trunked system; 
Individual call; 
On/Off hook signalling; 


No 


No 


Yes 


Quasi-transmission trunked system; 

Individual call; 

Direct set-up signalling; 


No 


No 


Yes 


Message trunked system; 
Group call; 


Yes 


No 


Yes 


Transmission trunked system; 
Group call; 


No 


No 


Yes 


Quasi-transmission trunked system; 
Group call; 


No 


No 


Yes 



For the called MSs/LSs in a group call, the traffic channel assignment should always be given along with 
the D-SETUP PDU. 



The following methods are available for assigning a traffic channel to a call: 
Early assignment: 

the traffic channels are assigned and indicated to the calling and called MS along with the 
D-CALL PROCEEDING and D-SETUP PDUs respectively (contained in the lower layer part 
of those messages). In this case the calling MS moves immediately to the traffic channel in 
anticipation of the call and should receive CC messages on this channel; 
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Medium assignment: 

the traffic channels are assigned and indicated to the calling MS along with the D-ALERT 
PDU and are indicated to the called MS in a layer 2 acknowledgement to the called MS 
U-ALERT PDU. In this case the calling MS moves to the traffic channel in anticipation of the 
call and should receive CC messages on this channel; 



Late assignment individual call: 

the traffic channels are not assigned until the called MS sends a U-CONNECT PDU. Upon 
reception of this PDU the traffic channels may be indicated to the calling and called MS along 
with the D-CONNECT and D-CONNECT ACKNOWLEDGE PDUs respectively In this case 
the calling MS shall remain listening on the control channel until it is told to move to the traffic 
channel; 



Late assignment group call: 

the traffic channels are not assigned until appropriate conditions are met. These conditions 
may be as a result of the finite time required to locate group members, or as a result of the 
call being acknowledged. The traffic channel may be indicated to the calling MS along with 
the D-CONNECT PDU. 



NOTE: When a MS is said to be sent to a traffic channel in the text above, it means that the 
MS is ordered to go to an assigned channel. For early and medium assignment, the 
assigned channel starts as a FACCH until the MS is instructed to switch the U-plane 
on. For late assignment, the MS may be instructed to switch the U-plane on when it 
moves to the assigned channel. 



1 4.5.4 SS procedures 

SS sub-entity 



c 



rb_route 



ROUTER 



c 




SS1) CSS2) CSS3J CSS4 





ROUTER 



re_route 



Figure 40: Internal view of SS sub-entity 



Figure 40 shows the internal architecture of the SS sub-entity. The user application shall communicate 
with SS entities via the rb-route, when the information of the requested service is not incorporated into 
TNCC-SAP service primitives, see clauses 11 and 12. All messages to and from PC shall be 
communicated over the re-route. When a SS message is received from the peer entity, it shall be passed 
via the SS router to the appropriate SS entity. 

Each individual SS entity shall receive and send call related SS messages as facility elements in CC 
PDUs, or if no call related PDU is available, in a U-INFO PDU. The call identifier element shall link the SS 
facility element to the related call. 

If the SS message is not related to any existing call, it shall be sent as a facility element in a U-FACILITY 
PDU. 

Some SS messages may be sent or received at any stage of a call, after the call during SS-CC retention 
time and when no call exists. 
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1 4.5.5 SDS procedures 

The SDS procedures handled by the SDS sub-entity shall be applicable for the MS/LS side. The 
procedures relating to the SwMI are outside the scope of this ETS. 

In the SDS protocol there is no relationship defined between SDS messages using different transmission 
directions and the SDS sub-entity shall be able to handle colliding messages, e.g. shall receive messages 
to be sent to the peer entity and shall deliver received messages from the peer entity at the same time. 

14.5.5.1 Incoming short data message 

On reception of D-STATUS or D-SDS-DATA PDUs the SDS sub-entity shall inform the user application 
with a TNSDS-STATUS indication primitive containing the pre-coded status or with a TNSDS-UNITDATA 
indication primitive containing user defined data, respectively. 

14.5.5.2 Outgoing short data messages 

A user application initiates the SDS message transfer by issuing either a TNSDS-STATUS request 
primitive or a TNSDS-UNITDATA request primitive. The SDS sub-entity shall select an appropriate PDU 
priority based on the requested access priority value as described in subclause 14.5.6.2. 

Upon reception of a TNSDS-STATUS or a TNSDS-UNITDATA request primitive the SDS sub-entity shall 
send the corresponding U-STATUS or U-SDS-DATA PDU respectively. 

The SDS sub-entity shall not accept further short data request primitives from the user application before 
a REPORT indication indicating successful transmission of the PDU has been received. The received 
report shall be forwarded to the user application in a TNSDS-REPORT indication. 

If the SDS entity receives a REPORT indication informing that the PDU transmission was unsuccessful, 
the SDS sub-entity shall inform the user application using a TNSDS-REPORT indication with parameter 
"failure" and the SDS sub-entity may continue to accept new SDS service requests. 

1 4.5.6 PC procedures 

This subclause contains various protocol elements which are common to one or more sub-entities within 
the CMCE. The description does not define or limit implementations to be inside the PC sub-entity. 

14.5.6.1 Access to the communication resources 

When the MS or LS is powered up all the CMCE sub-entities except the PC sub-entity shall start in state 
IDLE. The PC sub-entity shall start in state CLOSED. When the PC sub-entity receives a MLE-OPEN 
indication, the PC sub-entity shall change state to OPEN and inform other sub-entities with an OPEN 
indication. When the PC is in state CLOSED the other sub-entities shall not send any PDUs. When the PC 
receives a MLE-CLOSE indication, the PC sub-entity shall change state to CLOSED and shall inform the 
other sub-entities with a CLOSE indication primitive. 

Primitives MLE-BREAK indication, REOPEN indication, RESTORE confirm and RESUME indication shall 
not change the state of the PC, but PC shall pass those to other sub-entities as defined in 
subclause 14.2.6. 

1 4.5.6.2 Access priority handling 

When any CMCE sub-entity receives an access priority value in a TNCC, TNSS or TNSDS primitive, the 
sub-entity shall set the PDU priority value according to the access priority value. If the corresponding PDU 
priority is not defined by other means, then the sub-entity shall use default values as defined in table 57. 
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Table 57: Low/high/emergency PDU priority default values 



PDU 


PDU priority 


Remark 


U-ALERT 


2/4/7 


Stealinq repeats flag not set 


U-CALL-RESTORE 


5 


Stealinq repeats flag not set 


U-CONNECT 


2/4/7 


Stealinq repeats flag not set 


U-DISCONNECT 


6 


Immediate stealing and Stealing repeats flag set 


U-INFO 


2/4/7 


Stealing repeats flag not set 


U-RELEASE 


6 


Stealing repeats flag not set 


U-SETUP 


0/4/7 


Stealing repeats flag not set 


U-STATUS 


1/4/7 


Stealing repeats flag not set 


U-SDS DATA 


1/4/7 


Stealing repeats flag not set 


U-TX-CEASED 


6 


Immediate stealinq and Stealing repeats flag set 


U-TX-DEMAND 


2/4/7 


Stealing repeats flag not set 



For PDUs other than U-TX CEASED and U-DISCONNECT, the CC sub-entity shall set the stealing 
permission parameter according to the following rules: 



if "traffic stealing = steal traffic" and "access priority = emergency" in the service access primitive, 
the stealing permission parameter shall be set to "steal immediately"; 

if "traffic stealing = steal traffic" and access priority is not equal to "emergency" in the service 
access primitive, the stealing permission parameter shall be set to "steal when convenient"; 

otherwise the stealing permission parameter shall be set to "stealing not required". 
14.5.6.2.1 Cancel 

The cancel procedures may be implemented in an MS and if used the following shall apply: 

the MLE-CANCEL request can minimise the risk of adding extra load to the air interface, e.g. when 
a user application requests a call set-up and the request is buffered by the lower layers waiting for 
allowance to make a random access attempt, which in the case of a low priority call and high 
system load can take a considerable amount of time. If the user application, during this waiting 
period, changes its decision and wants to disconnect the call, the application shall send a 
TNCC-RELEASE request to the CC sub-entity. The CC sub-entity shall know the status of the 
transmission from the REPORT indications received from the lower layers; 

when any sub-entity wishes to stop transmission of a PDU it may use cancel procedure with the 
limitations defined below. The cancel process shall be controlled by REPORT indications from 
lower layers; 

incoming MLE-REPORT indications should indicate the following events: 

a PDU has been stored by the DLL ready for transmission. At this stage the transmission 
may be cancelled using a CANCEL request and no information will be sent over the air 
interface; 

the first transmission of whole PDU. The BS may have received the PDU, but MS has not yet 
received an acknowledgement. At this stage the layer 2 process may be stopped using a 
CANCEL request, but the sending sub-entity cannot rely on the cancellation and may receive 
a response to the sent PDU; 

the transfer of a PDU has failed in layer 2. Cancellation is no longer possible, but the BS may 
have received the PDU correctly and the sending sub-entity may receive a response to the 
sent PDU; 



a PDU has been successfully transmitted by layer 2. Cancellation is no longer possible. 
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1 4.5.6.3 CMCE PDU exchange 

The PC shall forward PDUs from the other CMCE sub-entities to MLE using a MLE-UNITDATA request 
primitive without modifying any parameters supplied with the PDU. However the U-CALL RESTORE PDU 
shall use a MLE-RESTORE request instead of the MLE-UNITDATA request. 

The PC shall forward the SDU contained in a received MLE-UNITDATA indication primitive to the 
corresponding sub-entity as defined by the PDU type element without modifying any parameters. The 
D-CALL RESTORE PDU should be received in a MLE-RESTORE confirm primitive instead of the 
MLE-UNITDATA indication. 

1 4.5.6.3.1 Choice of layer 2 service 

When sending the following PDUs, the PC should set the layer 2 service parameter to "acknowledged 
response": 

U-ALERT PDU; 

U-CONNECT PDU for direct call set-up; 

U-DISCONNECT PDU when sent as a response to a D-SETUP PDU; 
U-RELEASE. 

For other uplink PDUs, the PC should set the layer 2 service parameter to "acknowledged request". 

14.5.6.4 Control information exchange 

CMCE sub-entities exchange local control information with the PC using service primitives. 

The PC shall forward service primitives from other CMCE sub-entities to the MLE using MLE service 
primitives as defined in subclause 17.3.4 without any modification of the parameters. 

The PC shall forward service primitives from MLE, as defined in subclause 17.3.4 to the relevant 
sub-entity or sub-entities without any modification of parameters. 

The primitive names and parameters between the PC and the other sub-entities are same as the primitive 
names at the MLE-SAP except that the "MLE-" is not present. 

The CC protocol cannot support overlapping call set-up signalling within the window where the CC awaits 
a call identifier from the SwMI after a U-SETUP PDU is issued. A method to prevent concurrent call set-up 
attempt during the window is described as follows: 

when a CC instance initiates a call set-up, it shall inform PC that a call set-up has been initiated, 
and the PC shall inform other CC instances that currently no more call set-up attempts are possible; 

when the CC instance either receives a call identifier for the new call or discards the call set-up, it 
shall inform completion of call set-up to the PC, and the PC shall forward that information to the 
other CC instances. 

This method enables correct mapping between the call identifier and the appropriate CC instance. 
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14.5.6.5 PC protocol error conditions 

14.5.6.5.1 PDU Type error 

When a PDU is received with a PDU type not recognisable, the PC shall ignore that PDU. 

14.5.6.5.2 Invalid call identifier 

If any down link PDUs except D-SETUP and D-RELEASE are received specifying a call identifier element 
for an individual call which is not recognised as relating to an active call, to a call in progress or being a 
dummy call identifier in specified situations, the PC shall send a U-DISCONNECT PDU with the received 
invalid call identifier and with the cause "Invalid call identifier". 

If a D-RELEASE message is received with an unknown call identifier element, no action shall be taken by 
PC. 

14.5.6.5.3 MS busy 

If the MS cannot support more concurrent calls and does not release any, when it receives an individually 
addressed D-SETUP PDU, the MS shall send a U-DISCONNECT PDU back to the SwMI with cause 
"Busy". 

14.6 Protocol timers 

Table 58 lists the protocol timers and the information associated with them. 



Table 58: Timers 



Timer 
No. 


Timer 
Value 


Call State 


Cause for Start 


Normally 
terminated 


Action when 
timer Expires 


l/C 
Side 


O/G 
Side 


T301 
note 


Max. 30 
Seconds 


MT-CALL- 
Set-up 


On the sending of 
U-Connect 


On receipt of 
D-Connect Ack, 
D-Disconnect, 
D-Release, 
Report (failed) ind 


Disconnect as 
specified in 
subclause 
14.5.1.3.4 a) 


M 




T302 
note 


Max. 60 
seconds 


MO-CALL- 
Set-up 


On receipt of D-Call 
Proceeding, 
D-Alert 
or D-INFO 


On receipt of 
D-Connect, 
D-Disconnect, 
D-Release, 
Report (failed) ind 


Disconnect as 
specified in 
subclauses 

14.5.1.3.4 b) 
and 

14.5.2.3.5 a) 




M 


T303 


Max. 60 
seconds 


MO-CALL- 
Set-up 


On the sending of 
U-SETUP 


On receipt of 
D-Call Proceeding, 
D-Alert, 
D-Connect, 
D-Release, 
Report (failed) ind 
On transmission of 
U-Disconnect 


Disconnect as 
specified in 
subclauses 

14.5.1.3.4 c) 
and 

14.5.2.3.5 b) 




M 


(continued) 
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Table 58 (concluded): Timers 



Timer 


Timer 

Value 


Call State 


Cause for Start 


Normally 

terminated 

ICI 1 1 II 1 ICI ICU 


Action when 
timer Exoires 

III 1 ICI bApil w w 


I/C 
Side 


O/G 
Side 


T306 


Min 4 sec 
Max 6 sec 


Break 


On receipt of 

Resume ind 

(Pt - Pt calls only) 


On receipt of 
D-Call-Restore, 
Reopen ind 


Disconnect as 
specified in 
subclause 
14.5.1.3.4 d) 


M 


M 


T307 


Min 6 sec 
Max 8 sec 


Break 


On sending of U- 
uALL-nesiore \rl - 
MtPt calls only) 


Receipt of 
u-oan-nesiore, 
Reopen ind 


Disconnect as 

5p6CITIcU IN 

subclause 
14.5.2.3.5 c) 


M 


M 


T308 


Max. 10 
sec 


Any State 


On transmission of 
U-Disconnect 


Receipt of 
D-Release, 
Report (failed) ind 


Disconnect as 
specified in 
subclauses 

14.5.1.3.4 e) 
and 

14.5.2.3.5 d) 


M 


M 


T310 
note 


Min 5 sec 
No Max. 
See note 


Call Active 


On receipt of 

D-Connect, 

D-Connect- 

Acknowledge, 

D-TX-Continue, 

D-SETUP(Ptto 

Mtrt calls only) 


On receipt of 
D-Release, 
D-TX-Wait, 
Report (failed) ind 
On transmission 
of U-Disconnect, 
U-Release 


Disconnect as 
specified in 
subclauses 

14.5.1.3.4 f) 
and 

14.5.2.3.5 e) 


M 


M 


T311 


Max. 300 
sec 


Call Active 
TX 


On receipt of 
D-TX-Granted 
(transmit), 
D-TX-Continue 


On transmission 
of U-TX Ceased, 
U-Disconnect 
On receipt of 
D-TX Interrupt, D- 
Release, 
D-TX-Wait, 
Report (failed) ind 


Forced Ceased 
Transmission, 
i ransmission 
of U-TX 
Ceased 


M 


M 


T321 


Min 45 sec 


Call 

Disconn. 


Transmission of 

D-Disconnect, 

D-Release 


Implementation 
option 


Deletion of Call 
I.D. & related 
information. 


O 


O 


NOTE: 


This timer can be started again during the call. 









14.7 PDU descriptions 

The PDUs detailed within this subclause shall be visible at the Urn reference point. 



The general format of the PDUs are defined in table 59. 

The elements shall be transmitted in the order specified by the table with the top element being 
transmitted first (before interleaving). The content of an information element is represented by a binary 
value and the most significant bit of that binary value shall be transmitted first (before interleaving). 



Table 59: PDU layout 



Information element 


Length 


Value 


Remark 


PDU Type 


5 






Type 1 element (1) 


varies 




See definitions below. 


Type 1 element (2) 


varies 




See definitions below. 


...etc. 


...etc. 




...etc. 


Type 1 element (n) 


varies 




See definitions below. 


Optional bit (O-bit) 


1 


0 


No optional type 2 or type 3 elements follow 




1 


Optional type 2 or type 3 elements follow 


Presence bit (P-bit) (1) 


1 


0 


The type 2 element (1) is not present 






1 


The type 2 element (1) is present. 



(continued) 
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Table 59 (concluded): PDU layout 



Information element 


Length 


Value 


Remark 


Type 2 element (1) 


varies 




See definitions below. 


Presence bit (P-bit) (2) 


1 


0 


The type 2 element (2) is not present 




1 


The type 2 element (2) is present. 


Type 2 element (2) 


varies 




See definitions below. 


...etc. 


...etc. 




...etc. 


Presence bit (P-bit) (n) 


1 


0 


The type 2 element (n) is not present 




1 


The type 2 element (n) is present. 


Type 2 element (n) 


varies 




See Type 2 element (1) 


More bit (M-bit) (1) 


1 


0 


No type 3 elements follow 




1 


Type 3 elements follow 


Type 3 Element Identifier (1) 


4 




See definitions below. 


Length indicator (1) 


11 


0 


Reserved for possible future use. 




1-2 047 10 


Lenqth of the following type 3 Element in bits: 


Type 3 Element (1) 


varies 




See definitions below. 


More bit (M-bit) (2) 


1 


0 


No more type 3 elements follow 




1 


More type 3 elements follow 


Type 3 Element Identifier (2) 


4 




See definitions below. 


Length indicator (2) 


11 


0 


Reserved for possible future use. 




1-2 047 10 


Length of the following type 3 Element in bits: 


Type 3 Element (2) 


varies 




See definitions below. 


...etc. 


...etc. 




...etc. 


More bit (M-bit) (n) 


1 


0 


No more type 3 elements follow 




1 


More type 3 elements follow 


Type 3 Element Identifier (n) 


4 




See definitions below. 


Length indicator (n) 


11 


0 


Reserved for possible future use. 




1-2 047 10 


Lenqth of the following type 3 Element in bits: 


Type 3 Element (n) 


varies 




See definitions below. 


More bit (M-bit) (n+1) = 0 


1 


0 


Last M-bit (Least Significant Bit in the PDU) = 0 



The element type defines the encoding rule applied to an element as follows: 

Type 1 elements shall be placed within the PDU in a fixed order as specified in the PDU description 
tables. The elements shall have fixed lengths as specified in the length column or variable lengths 
as indicated by a preceding length element. Each Type 1 element shall either be a mandatory 
element or conditional to a mandatory element. Type 1 elements shall be placed before any Type 2 
or Type 3 elements in the PDU. The last Type 1 element shall be followed by an O-bit. When the 
PDU contains any Type 2 or Type 3 elements the O-bit shall set to 1 . When the PDU does not 
contain any Type 2 or Type 3 elements the O-bit shall be set to 0; 

Type 2 elements are either optional or conditional to an optional element and shall be placed within 
the PDU in a fixed order as specified in the PDU description tables. There shall be one P-bit 
preceding each Type 2 optional element specified for the PDU to indicate presence of that element. 
The P-bit shall indicate either "Type 2 element present" or "Type 2 element not present". Type 2 
elements shall have fixed lengths as specified in the length column of the PDU description tables. 
Type 2 elements shall be placed after all Type 1 elements and before any Type 3 elements in the 
PDU; 

Type 3 elements are optional and shall be placed within the PDU in numerical order as specified 
within the "Type 3 Element Identifier" element. Type 3 Elements shall be placed after any Type 1 
and Type 2 elements. If there are any Type 3 elements specified for the PDU an M-bit shall follow 
the Type 1 and Type 2 elements. The M-bit shall indicate either "Type 3 element to follow" or "no 
Type 3 element to follow". If there are Type 3 elements to follow, they shall be preceded by a "Type 
3 Element Identifier" element and a "Length Indicator" element in that order. A further M-bit shall 
follow the Type 3 element and after the last Type 3 element included the M-bit shall be set to 0 to 
indicate "no Type 3 element to follow". Type 3 element coding can contain sub-element s which can 
be either of Type 1 , 2 or 3. 



Page 166 

ETS 300 392-2: March 1996 



Element lengths, values and contents are specified in subclause 14.8 and a specific element can be used 
either as type 1 , 2 or 3 depending on the PDU. 

The following rules shall apply for decoding of the PDU: 

DO for all possible Type 1 elements 
IF element is not a conditional element 
THEN DECODE Type 1 element 

ELSE DECODE conditional Type 1 element if indicated 
END DO 

DECODE O-bit 

IF O-bit set to 'No Optional Elements present' 
THEN END of PDU decoding 
ELSE 

DO for all possible Type 2 elements 
DECODE P-bit 

IF P-bit set to 'Present' 

THEN DECODE Type 2 element AND 

IF element points to conditional element {s) 

THEN DECODE indicated conditional element (s) , END IF 
IF P-bit not set 'Present' 

THEN pass also elements conditional on that element 

END DO 

WHILE M-bit set to 'More Type 3 elements follows' 

DECODE Type 3 element 
END WHILE 
END of PDU decoding. 

NOTE: There is only one P-bit common for a type 2 optional element and any element(s) 
conditional on the first element. In this case the conditional element(s) follow 
immediately the first element (without a P-bit between them). 

The information contained in the following PDU description tables corresponds to the following key: 

Length: length of the element in bits; 

Type: element type (1 , 2, or 3) as defined above; 

Owner: sub-entity responsible for (or owner of) the element data; 

C/O/M: conditional/optional/mandatory information in the PDU; 

Remark: comment. 



1 4.7.1 PDU description tables - downlink 

14.7.1.1 D-ALERT 

Message: D-ALERT 
Response to: U-SETUP 
Response expected: 

Short description: This PDU shall be an information to the originating MS/LS that the call is 

proceeding and the connecting party has been alerted. 



Table 60: D-ALERT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 




Call identifier 


14 




CC 


M 




Call time-out, set-up phase 


3 




CC 


M 




Hook method selection 


1 




CC 


M 




Simplex/duplex selection 


1 




CC 


M 




Call queued 


1 




CC 


M 




Basic service information 


8 


2 


CC 


0 


note 


Notification indicator 


6 


2 


ss 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




o 




NOTE: If different from requested. 
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1 4.7.1 .2 D-CALL PROCEEDING 

Message: D-CALL PROCEEDING 

Response to: U-SETUP 
Response expected: 

Short description: This PDU shall be the acknowledgement from the infrastructure to call set-up 

request indicating that the call is proceeding. 

Table 61: D-CALL PROCEEDING PDU contents 



Information element 


Length 


Type 


Owner 


C/O/WI 


Remark 


PDU Type 


5 




CC 


M 




Call identifier 


14 




cc 


M 




Call time-out, set-up phase 


3 




CC 


M 




Hook method selection 


1 




cc 


M 




Simplex/duplex selection 


1 




cc 


M 




Basic service information 


8 


2 


cc 


O 


note 


Call status 


3 


2 


cc 


O 




Notification indicator 


6 


2 


ss 


0 




Facility 




3 


ss 


O 




Proprietary 




3 




0 




NOTE: If different from requested. 



14.7.1.3 D-CALL-RESTORE 



Message: D-CALL-RESTORE 
Response to: 
Response expected: 

Short description: This PDU shall indicate to the MS/LS that a call has been restored after a 

temporary break of the call. 



Table 62: D-CALL RESTORE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 




Call identifier 


14 




CC 


M 




Transmission grant 


2 




CC 


M 




Transmission request permission 


1 




cc 


M 




Reset call time-out timer (T310) 


1 




cc 


M 




New call identifier 


14 


2 


cc 


0 




Call time-out 


4 


2 


cc 


0 




Call status 


3 


2 


cc 


0 




Modify 


9 


2 


cc 


O 




Notification indicator 


6 


2 


ss 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




0 
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14.7.1.4 D-CONNECT 

Message: D-CONNECT 

Response to: U-SETUP 
Response expected: 

Short description: This PDU shall be the order to the calling MS/LS to through-connect. 



Table 63: D-CONNECT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/WI 


Remark 


PDU Type 


5 




CC 


M 




Call identifier 


14 




CC 


M 




Call time-out 


4 




CC 


M 




Hook method selection 


1 




CC 


M 




Simplex/duplex selection 


1 




CC 


M 




Transmission grant 


2 




CC 


M 




Transmission request permission 


1 




CC 


M 




Call ownership 


1 




CC 


M 




Call priority 


4 


2 


CC 


0 




Basic service information 


8 


2 


CC 


0 


note 


Temporary address 


24 


2 


CC 


0 




Notification indicator 


6 


2 


ss 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




0 




NOTE: If different from requested. 



14.7.1 .5 D-CONNECT ACKNOWLEDGE 



Message: D-CONNECT ACKNOWLEDGE 

Response to: U-CONN ECT 
Response expected: 

Short description: This PDU shall be the order to the called MS/LS to through-connect. 



Table 64: D-CONNECT ACKNOWLEDGE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 




Call identifier 


14 




CC 


M 




Call time-out 


4 




CC 


M 




Transmission grant 


2 




CC 


M 




Transmission request permission 


1 




CC 


M 




Notification indicator 


6 


2 


ss 


0 




Facility 




3 


ss 


o 




Proprietary 




3 




0 
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14.7.1.6 D-DISCONNECT 

Message: D-DISCONNECT 
Response to: 

Response expected: U-RELEASE 

Short description: This PDU shall be the disconnect request message sent from the infrastructure 

to the MS/LS. 



Table 65: D-DISCONNECT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


cc 


M 




Disconnect cause 


5 


1 


CC 


M 




Notification indicator 


6 


2 


ss 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




0 





14.7.1.7 D-FACILITY 



Message: D-FACILITY 
Response to: 
Response expected: 

Short description: This PDU shall be used to send call unrelated SS information. 

Table 66: D-FACILITY PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


SS 


M 


note 


NOTE: Contents of this PDU shall be defined by SS protocols. 
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14.7.1.8 D-INFO 

Message: D-INFO 
Response to: 
Response expected: 

Short description: This PDU shall be the general information message to the MS/LS. 

Table 67: D-INFO PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


CC 


M 


note 1 


Reset call time-out timer (T310) 


1 


1 


CC 


M 




Poll request 


1 


1 


CC 


M 


note 2 


New call identifier 


14 


2 


CC 


0 




Call time-out 


4 


2 


CC 


0 




Call time-out set-up phase 


3 


2 


CC 


0 




Call ownership 


1 


2 


CC 


0 




Modify 


9 


2 


CC 


0 




Call status 


3 


2 


CC 


0 




Temporary address 


24 


2 


CC 


0 




Notification indicator 


6 


2 


SS 


0 




Poll response percentage 


6 


2 


CC 


0 


note 3 


Poll response number 


6 


2 


CC 


0 


note 3 


DTMF 




3 


CC 


0 




Facility 




3 


SS 


0 




Poll response addresses 




3 


CC 


0 


note 3 


Proprietary 




3 




o 




NOTE 1 : If the message is sent connectionless the call identifier shall be the dummy call identifier. 


NOTE 2: Shall be valid for acknowledged group call only. For other types of calls it shall be set = 0. 


NOTE 3: Shall be valid for acknowledged group call only. 









14.7.1.9 D-RELEASE 



Message: D-RELEASE 
Response to: -/U-DISCONNECT 
Response expected: 

Short description: This PDU shall be a message from the infrastructure to the MS/LS to inform that 

the connection has been released. 



Table 68: D-RELEASE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


CC 


M 




Disconnect cause 


5 


1 


CC 


M 




Notification indicator 


6 


2 


SS 


0 




Facility 




3 


SS 


0 




Proprietary 




3 




0 
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14.7.1.10 D-SDS-DATA 

Message: D-SDS-DATA 
Response to: 
Response expected: 

Short description: This PDU shall be for receiving user defined SDS data. 

Table 69: D-SDS-DATA PDU contents 



Information element 



Length 



Type 



Owner 



C/O/M 



Remark 



PDU Type 



SDS 



M 



Calling party type identifier 



SDS 



M 



Calling party address SSI 



24 



SDS 



note 1 



Calling party extension 



24 



SDS 



note 1 



Short data type identifier 



SDS 



M 



User defined data-1 



16 



SDS 



note 2 



User defined data-2 



32 



SDS 



note 2 



User defined data-3 



64 



SDS 



note 2 



Length indicator 



11 



SDS 



note 2 



User defined data-4 



SDS 



note 2 



Facility 



SS 



NOTE 1 : 



NOTE 2: 



Shall be conditional on the value of Calling Party Type Identifier (CPTI): 

CPTI = 1; Calling Party SSI; 

CPTI = 2; Calling Party SSI + Calling Party Extension. 

Shall be conditional on the value of Short Data Type Identifier (SDTI): 

SDTI = 0; User Defined Data-1; 

SDTI = 1; User Defined Data-2; 

SDTI = 2; User Defined Data-3; 

SDTI = 3; Length Indicator + User Defined Data-4. 



14.7.1.11 



D-STATUS 



Message: 
Response to: 
Response expected: 
Short description: 



D-STATUS 

This PDU shall be the PDU for receiving a pre-coded status message. 
Table 70: D-STATUS PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




SDS 


M 




Calling party type identifier 


2 




SDS 


M 




Calling party address SSI 


24 




SDS 


C 


note 


Calling party extension 


24 




SDS 


C 


note 


Pre-coded status 


16 




SDS 


M 




Facility 




3 


SS 


O 




NOTE: Shall be conditional on the value of Calling Party Type Identifier (CPTI): 
CPTI = 1; Calling Party SSI; 

CPTI = 2; Calling Party SSI + Calling Party Extension. 
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14.7.1.12 D-SETUP 

Message: D-SETUP 
Response to: 

Response expected: U-ALERT/U-CONNECT/- 

Short description: This PDU shall be the call set-up message sent to the called MS/LS. 

Table 71: D-SETUP PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


cc 


M 




Call time-out 


4 




CC 


M 




Hook method selection 


1 




cc 


M 




Simplex/duplex selection 


1 




cc 


M 




Basic service information 


8 




cc 


M 




Transmission grant 


2 




cc 


M 




Transmission request permission 


1 




cc 


M 




Call priority 


4 




cc 


M 




Notification indicator 


6 


2 


ss 


0 




Temporary address 


24 


2 


cc 


0 




Calling party type identifier 


2 


2 


cc 


o 




Calling party address SSI 


24 


2 


cc 


c 


note 


Calling party extension 


24 


2 


cc 


c 


note 


External subscriber number 




3 


cc 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




0 




NOTE: Shall be conditional on the value of Calling Party Type Identifier (CPTI): 
CPTI = 1; Calling Party SSI; 
CPTI = 2; Calling Party SSI + Calling Party Extension. 



14.7.1.13 D-TX CEASED 



Message: D-TX CEASED 

Response to: U-TX CEASED 

Response expected: 

Short description: This PDU shall be the PDU from the SwMI to all MS/LS within a call that a 

transmission has ceased. 



Table 72: D-TX CEASED PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


CC 


M 




Transmission request permission 


1 


1 


cc 


M 




Notification indicator 


6 


2 


ss 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




o 
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14.7.1.14 D-TX CONTINUE 

Message: D-TX CONTINUE 

Response to: 
Response expected: 

Short description: This PDU shall be the information from the SwMI to the MS/LS that the 

interruption of the call has ceased. 



Table 73: D-TX CONTINUE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


cc 


M 




Continue 


1 


1 


CC 


M 




Transmission request permission 


1 


1 


cc 


M 




Notification indicator 


6 


2 


ss 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




0 





14.7.1.15 D-TX GRANTED 



Message: D-TX GRANTED 

Response to: U-TX DEMAND 

Response expected: 

Short description: This PDU shall inform the MS/LS concerned with a call that permission to 

transmit has been granted by the SwMI to one MS/LS, and to inform that one 
MS/LS that it has been granted permission to transmit. 



Table 74: D-TX GRANTED PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 




Call identifier 


14 




CC 


M 




Transmission grant 


2 




cc 


M 




Transmission request permission 


1 




CC 


M 




Encryption control 


1 




CC 


M 




Speech service 


1 




CC 


M 




Notification indicator 


6 


2 


SS 


O 




Transmitting party type identifier 


2 


2 


CC 


O 




Transmitting party address SSI 


24 


2 


CC 


C 


note 


Transmitting party extension 


24 


2 


CC 


C 


note 


Facility 




3 


SS 


O 




Proprietary 




3 




O 




NOTE: Shall be conditional on the value of Transmitting Party Type Identifier (TPTI): 
TPTI = 1; Transmitting Party SSI; 

TPTI = 2; Transmitting Party SSI + Transmitting Party Extension. 
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14.7.1.16 D-TX INTERRUPT 

Message: D-TX INTERRUPT 

Response to: 
Response expected: 

Short description: This PDU shall be a message from the SwMI indicating that a permission to 

transmit has been withdrawn. 



Table 75: D-TX INTERRUPT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/WI 


Remark 


PDU Type 


5 




CC 


M 




Call identifier 


14 




CC 


M 




Transmission grant 


2 




CC 


M 




Transmission request permission 


1 




CC 


M 




Encryption control 


1 




CC 


M 




Speech service 


1 




CC 


M 




Notification indicator 


6 


2 


SS 


0 




Transmitting party type identifier 


2 


2 


CC 


0 




Transmitting party address SSI 


24 


2 


CC 


c 


note 


Transmitting party extension 


24 


2 


CC 


c 


note 


Facility 




3 


SS 


0 




Proprietary 




3 




0 




NOTE: Shall be conditional on the value of Transmitting Party Type Identifier (TPTI): 
TPTI = 1 ; Transmitting Party SSI; 

TPTI = 2; Transmitting Party SSI + Transmitting Party Extension. 



14.7.1.17 D-TX WAIT 



Message: D-TX WAIT 

Response to: U-TX DEMAND 
Response expected: 

Short description: This PDU shall be a message from the SwMI that the call is being interrupted. 



Table 76: D-TX WAIT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


CC 


M 




Transmission reguest permission 


1 


1 


CC 


M 




Notification indicator 


6 


2 


SS 


0 




Facility 




3 


SS 


0 




Proprietary 




3 




O 
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1 4.7.2 PDU description tables - uplink 

14.7.2.1 U-ALERT 

Message: U-ALERT 
Response to: D-SETUP 
Response expected: 

Short description: This PDU shall be a acknowledgement from the called MS/LS that the called 

user has been alerted. 



Table 77: U-ALERT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


cc 


M 




Hook method selection 


1 


1 


CC 


M 




Simplex/duplex selection 


1 


1 


cc 


M 




Basic service information 


8 


2 


cc 


O 




Facility 




3 


ss 


0 




Proprietary 




3 




o 





1 4.7.2.2 U-C ALL-RESTORE 



Message: U-CALL-RESTORE 
Response to: 

Response expected: D-CALL-RESTORE 

Short description: This PDU shall be the order from the MS/LS for restoration of a specific call 

after a temporary break of the call. 



Table 78: U-CALL RESTORE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 




Call identifier 


14 




CC 


M 




Request to transmit/send data 


1 




cc 


M 




Called party type identifier 


2 




cc 


M 




Called party short number address 


8 




cc 


c 


note 1 


Called party SSI 


24 




cc 


C 


note 1 


Called party extension 


24 




cc 


C 


note 1 


Basic service information 


8 


2 


cc 


0 


note 2 


Facility 




3 


ss 


O 




Proprietary 




3 




0 




NOTE 1 : Shall be conditional on the value of Called Party Type Identifier (CPTI): 

CPTI = 0; Called Party SNA; 

CPTI = 1; Called Party SSI; 

CPTI = 2; Called Party SSI + Called Party Extension. 
NOTE 2: Informs new cell of the basic service of the current call in progress. 
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14.7.2.3 U-CONNECT 

Message: U-CONNECT 

Response to: D-SETUP 

Response expected: D-CONNECT ACKNOWLEDGE- 

Short description: This PDU shall be the acknowledgement to the SwMI that the called MS/LS is 
ready for through-connection. 

Table 79: U-CONNECT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


cc 


M 




Hook method selection 


1 


1 


CC 


M 




Simplex/duplex selection 


1 


1 


cc 


M 




Basic service information 


8 


2 


cc 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




0 





14.7.2.4 U-DISCONNECT 



Message: U-DISCONNECT 
Response to: 

Response expected: D-DISCONNECT/D-RELEASE 

Short description: This PDU shall be the MS/LS request to the SwMI to disconnect a call. 

Table 80: U-DISCONNECT PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


CC 


M 




Disconnect cause 


5 


1 


cc 


M 




Facility 




3 


ss 


O 




Proprietary 




3 




0 





14.7.2.5 U-FACIUTY 



Message: U-FACIUTY 
Response to: 
Response expected: 

Short description: This PDU shall be used to send call unrelated SS information. 

Table 81 : U-FACILITY PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


SS 


M 


note 


NOTE: Contents of this PDU shall be defined by SS protocols. 



Page 177 
ETS 300 392-2: March 1996 



14.7.2.6 U-INFO 

Message: U-INFO 
Response to: 
Response expected: 

Short description: This PDU shall be the general information message from the MS/LS. 

Table 82: U-INFO PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


cc 


M 


note 1 


Poll response 


1 


1 


CC 


M 


note 2 


Modify 


9 


2 


cc 


0 




DTMF 




3 


cc 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




0 




NOTE 1 : If the message is sent connectionless then the call identifier shall be equal to the dummy 
call identifier. 

NOTE 2: Shall be valid for acknowledged group call only. For other types of call it shall be set equal 
to zero. 



14.7.2.7 U-STATUS 



Message: U-STATUS 
Response to: 
Response expected: 

Short description: This PDU shall be used for sending a pre-coded status message. 



Table 83: U-STATUS PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




SDS 


M 




Area selection 


4 




SDS 


M 




Called party type identifier 


2 




SDS 


M 


Short/SSI/TSI 


Called party short number address 


8 




SDS 


C 


note 


Called party SSI 


24 




SDS 


C 


note 


Called party extension 


24 




SDS 


C 


note 


Pre-coded status 


16 




SDS 


M 




External subscriber number 




3 


SDS 


0 




Facility 




3 


SS 


0 




NOTE: Shall be conditional on the value of Called Party Type Identifier (CPTI): 
CPTI = 0; Called Party SNA; 
CPTI = 1; Called Party SSI; 
CPTI = 2; Called Party SSI + Called Party Extension. 
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14.7.2.8 U-SDS-DATA 

Message: U-SDS-DATA 
Response to: 
Response expected: 

Short description: This PDU shall be for sending user defined SDS data. 

Table 84: U-SDS-DATA PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




SDS 


M 




Area selection 


4 




SDS 


M 




Called party type identifier 


2 




SDS 


M 


Short/SSI/TSI 


Called party short number address 


8 




SDS 


C 


note 1 


Called party SSI 


24 




SDS 


C 


note 1 


Called party extension 


24 




SDS 


c 


note 1 


Short data type identifier 


2 




SDS 


M 


note 3 


User defined data-1 


16 




SDS 


c 


note 2, note 3 


User defined data-2 


32 




SDS 


c 


note 2, note 3 


User defined data-3 


64 




SDS 


c 


note 2, note 3 


Length indicator 


11 




SDS 


c 


note 2 


User defined data-4 






SDS 


c 


note 2, note 4 


External subscriber number 




3 


SDS 


0 




Facility 




3 


SS 


0 




NOTE 1 : 
NOTE 2: 

NOTE 3 
NOTE 4 


Shall be conditional on the value of Called Party Type Identifier (CPTI): 

CPTI = 0; Called Party SNA; 

CPTI = 1; Called Party SSI; 

CPTI = 2; Called Party SSI + Called Party Extension. 

Shall be conditional on the value of Short Data Type Identifier (SDTI): 

SDTI = 0; User Defined Data-1 ; 

SDTI = 1; User Defined Data-2; 

SDTI = 2; User Defined Data-3; 

SDTI = 3; Length indicator + User Defined Data-4. 

Any combination of address and user defined data type is allowed. However, the intention 
is to fit TNSDS-UNITDATA request into one subslot when possible. It is recommended 
that always the shortest appropriate user defined data type is used. One subslot signalling 
is possible by using one of the following combinations: 

- Short Number Address & User Defined Data 1 or 2; 

- Short Subscriber Identity & User Defined Data 1 . 

The length of user defined data 4 is between 0 and 2 047 bits. However, if the basic link is 
to be used, then the longest recommended length of the user defined data 4 is 1 017 bits 
while using Short Subscriber Identity and FCS (See subclause 4.2.1 , note 2). 



14.7.2.9 U-RELEASE 



Message: U-RELEASE 

Response to: D-DISCONNECT 
Response expected: 

Short description: This PDU shall be the acknowledgement to a disconnection. 



Table 85: U-RELEASE PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


1 


CC 


M 




Call identifier 


14 


1 


CC 


M 




Disconnect cause 


5 


1 


CC 


M 




Facility 




3 


SS 


O 




Proprietary 




3 




O 
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14.7.2.10 U-SETUP 

Message: U-SETUP 
Response to: 

Response expected: D-CALL PROCEEDING/D-ALERT/D-CONNECT 

Short description: This PDU shall be the request for a call set-up from a MS/LS. 

Table 86: U-SETUP PDU contents 



Information element 


Length 


Type 


Owner 


C/U/M 


Remark 


PDU Type 


5 




cc 


M 




Area selection 


4 




cc 


M 




Hook method selection 


1 




cc 


M 




Simplex/duplex selection 


1 




cc 


M 




Basic service information 


8 




cc 


M 




Request to transmit/send data 


1 




cc 


M 




Call priority 


4 




cc 


M 




Reserved 


2 






M 


note 1 


Called party type identifier 


2 




cc 


M 


Short/SSI/TSI 


Called party short number address 


8 




cc 


C 


note 2 


Called party SSI 


24 




cc 


C 


note 2 


Called party extension 


24 




cc 


C 


note 2 


External subscriber number 




3 


cc 


0 




Facility 




3 


ss 


0 




Proprietary 




3 




O 




NOTE 1 : Not used in this version of the ETS. The default value shall be 00 2 . 
NOTE 2: Shall be conditional on the value of Called Party Type Identifier (CPTI): 

CPTI = 0; Called Party SNA; 

CPTI = 1; Called Party SSI; 

CPTI = 2; Called Party SSI + Called Party Extension. 



14.7.2.11 U-TX CEASED 



Message: U-TX CEASED 
Response to: 

Response expected: D-TX CEASED/D-TX GRANTED/D-TX WAIT 

Short description: This PDU shall be the message to the SwMI that a transmission has ceased. 



Table 87: U-TX CEASED PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 


■ 1 


CC . 


M 




Call identifier 


14 


1 


CC 


M 




Facility 




3 


ss 


O 




Proprietary 




3 




o 
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14.7.2.12 U-TX DEMAND 

Message: U-TX DEMAND 

Response to: 
Response expected: 

Short description: This PDU shall be the message to the SwMI that a transmission is requested. 

Table 88: U-TX DEMAND PDU contents 



Information element 


Length 


Type 


Owner 


C/O/M 


Remark 


PDU Type 


5 




CC 


M 




Call identifier 


14 




CC 


M 




TX demand priority 


2 




cc 


M 




Encryption control 


1 




cc 


M 




Speech service 


1 




cc 


M 




Facility 




3 


ss 


O 




Proprietary 




3 




0 





14.8 Information elements coding 



Any of the following elements can be coded as Type 1, 2 or 3 depending on the PDU (see 
subclause 14.7). 

1 4.8.1 Area Selection (AS) 

The purpose of the AS element shall be to indicate to the SwMI the distribution of the call. 



Table 89: AS element contents 



Information element 


Length 


Value 


Remark 


Area Selection 


4 


0000 2 


Area not defined 






0001? 


Area 1 






001 Op 


Area 2 






...etc. 


...etc. 






1110? 


Area 14 






1111? 


All areas this system 
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1 4.8.2 Basic service information 

The purpose of the basic service information element shall be to inform the SwMI what basic service is 
requested. The element length is 8 bits. 



Table 90: Basic service information element contents 



Information sub-element 


Length 


Value 


Remark 


Circuit Mode Type 


3 


000? 


Speech: TCH/S 


(see note 1) 




001 2 


Unprotected: TCH/7,2 






01 0 2 


Low Protection: TCH/4,8, N=1 






011 2 


Low Protection: TCH/4,8, N=4 






100? 


Low Protection: TCH/4,8, N=8 






101? 


High Protection: TCH/2,4, N=1 






110? 


High Protection: TCH/2,4, N=4 






111 2 


High Protection: TCH/2,4, N=8 


Encryption Flag 


1 


0 


Clear Mode 


(see note 2) 




1 


TETRA end-to-end encryption 


Communication Type 


2 


00 2 


Point-to-point 






01 2 


Point-to-multipoint 






10? 


Point-to-multipoint Acknowledged 






112 


Broadcast 


Slots per frame 


2 


00? 


One slot 


(see note 3) 




01? 


Two slots 






10? 


Three slots 






11p 


Four slots 


NOTE 1 : Indicates the TCH type and the interleaving depth N (see clause 8). 

NOTE 2: Indicates whether the circuit mode speech or data is end-to-end encrypted. 

NOTE 3: Indicates the required bit rate for a circuit mode data call. For TCH/7,2, TCH/4,8 and 
TCH/2,4 the resulting bit rate is the TCH bit rate multiplied by the number of slots per 
frame, (e.g. TCH/7,2 in four time slots per frame gives a circuit mode data rate of 
28,8 kbit/s). For TCH/S this element shall be present (set to 0). 



14.8.3 Call identifier 



The purpose of the call identifier element shall be to uniquely identify a specific call. 



Table 91 : Call identifier element contents 



Information element 


Length 


Value 


Remark 


Call identifier 


14 


0 


dummy call identifier 






1 10 -16 383io 


identifies call uniquely 



1 4.8.4 Call ownership 

The purpose of the call ownership element in a group call shall be to indicate to the MS whether it is 
capable to disconnect the call or not. In individual call it indicates to both parties if it is a normal call set-up 
or if it is amalgamated call. 

Table 92: Call ownership element contents 



Information element 


Length 


Value 


Remark 


Call ownership 


1 


0 


Not a call owner (Group call); 
Normal call set-up (Individual call). 






1 


A call owner (Group call); 
Amalgamated call (Individual call). 
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1 4.8.5 Called party type Identifier 

The purpose of the called party type identifier element shall be to indicate the type of address which shall 
follow in the PDU. 



Table 93: Called party type identifier element contents 



Information element 


Length 


Value 


Remark 


Called party type identifier 


2 


00? 


Short Number Address (SNA) 






01? 


Short Subscriber Identity (SSI) 






10? 


TETRA Subscriber Identity (TSI) 






11 2 


Reserved. 



14.8.6 Called party SNA 



The purpose of the called party SNA element shall be to indicate to the SwMI the SNA of the called user. 



Table 94: Called party SNA element contents 



Information element 


Length 


Value 


Remark 


Called party Short Number Address 


8 


0 - 255m 


See ETS 300 392-1 [1 11, clause 7. 



14.8.7 Called party extension 



The purpose of the called party extension element shall be to indicate to the SwMI the extended part of 
the TSI address of the called user. 



Table 95: Called party extension element contents 



Information sub-element 


Length 


Value 


Remark 


Country Code 


10 




See ETS 300 392-1 [1 1], clause 7. 


Network Code 


14 




See ETS 300 392-1 [1 11, clause 7. 



14.8.8 Called party SSI 

The purpose of the Called party SSI element shall be to indicate to the SwMI the SSI address of the called 
user. 



Table 96: Called party SSI element contents 



Information element 


Length 


Value 


Remark 


Short Subscriber Identity (SSI) 


24 




See ETS 300 392-1 [1 11, clause 7. 



14.8.9 Calling party type identifier 

The purpose of the calling party type identifier element coding shall be to indicate the type of address 
which shall follow in the PDU. 



Table 97: Calling party type identifier element contents 



Information element 


Length 


Value 


Remark 


Calling Party Type Identifier 


2 


00 2 


Reserved. 






01? 


Short Subscriber Identity (SSI) 






10? 


TETRA Subscriber Identity (TSI) 






11? 


Reserved. 
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1 4.8.1 0 Calling party extension 

The purpose of the calling party extension element shall be to indicate the extended part of the TSI 
address of the calling user. 



Table 98: Calling party extension element contents 



Information sub-element 


Length 


Value 


Remark 


Country Code 


10 




See ETS 300 392-1 [1 1] clause 7. 


Network Code 


14 




See ETS 300 392-1 [11] clause 7. 



14.8.11 Calling party SSI 

The purpose of the Calling party SSI element shall be to indicate the SSI address of the calling user. 

Table 99: Calling party SSI element contents 



Information element 


Length 


Value 


Remark 


Short Subscriber Identity (SSI) 


24 




See ETS 300 392-1 [11] clause 7. 



14.8.12 Call priority 

The purpose of the call priority element shall be to inform the SwMI or the MS/LS about the call priority. 



Table 100: Call priority element contents 



Information element 


Length 


Value 


Remark 


Call priority 


4 


0000? 


Priority not defined 






0001 2 


Priority 1 (Lowest Priority) 






0010? 


Priority 2 






...etc. 


...etc. 






1011? 


Priority 1 1 






1100? 


Pre-emptive priority 1 






1101? 


Pre-emptive priority 2 






1110? 


Pre-emptive priority 3; 






1111? 


Pre-emptive priority 4 (Emergency) 



14.8.13 Call status 



The purpose of the call status element shall be to inform the MS/LS about the status of the call. 



Table 101: Call status element contents 



Information element 


Length 


Value 


Remark 


Call status 


3 


000? 


Call is progressing 






001? 


Call is queued 






010? 


Requested subscriber is paged 






011? 


Call Continue 






100? 


Hanq time expired 






101? 


Reserved; 






110? 


Reserved; 






111? 


Reserved; 
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14.8.14 Call queued 

The purpose of the call queued element shall be to inform the calling MS/LS that the call has been put in 
queue. 



Table 102: Call queued element contents 



Information element 


Length 


Value 


Remark 


Call queued 


1 


0 


Call is not queued 






1 


Call is queued 



14.8.15 Continue 



The purpose of the continue element is to inform the MS/LS if it shall continue after a pause in the same 
state as before the pause. 



Table 103: Continue element contents 



Information element 


Length 


Value 


Remark 


Continue 


1 


0 


Not continue 






1 


Continue 



14.8.16 Call time-out 



The purpose of the call time-out element shall be to set the maximum call time (T310). 



Table 104: Call time-out element contents 



Information element 


Length 


Value 


Remark 


Call time-out 


4 


0000 2 


Infinite Time 






0001 2 


30 seconds 






001 Op 


45 seconds 






001 1? 


60 seconds 






01002 


2 minutes 






0101? 


3 minutes 






0110? 


4 minutes 






0111? 


5 minutes 






10002 


6 minutes 






1001? 


8 minutes 






1010? 


10 minutes 






1011? 


12 minutes 






1100? 


15 minutes 






1101? 


20 minutes 






1110? 


30 minutes 






1111? 


Reserved 
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1 4.8.1 7 Call time-out, set-up phase 

The purpose of the call time-out, set-up phase element (T301 and T302) shall be to set the maximum 
set-up time valid for the call set-up phase. 



Table 105: Call time-out, set-up phase element contents 



Information element 


Length 


Value 


Remark 


Call time-out, set-up phase 


3 


000? 


Use predefined value, note 






001 2 


1 second 






010? 


2 seconds 






011 2 


5 seconds 






100 2 


10 seconds 






101? 


20 seconds 






1102 


30 seconds 






111 2 


60 seconds 


NOTE: This value shall indicate that the MS/LS shall use a predefined value for the timer. 



14.8.18 Disconnect cause 



The purpose of the disconnect cause element shall be to inform the MS/LS or the infrastructure of the 
reason for the release/disconnection. 



Table 106: Disconnect cause element contents 



Information element 


Length 


Value 


Remark 


Disconnect cause 


5 


OOOOO2 


Cause not defined or unknown 






00001? 


User requested disconnect 






00010? 


Called party busy 






00011? 


Called party not reachable 






001 00 2 


Called party does not support encryption 






001 01 2 


Conqestion in infrastructure 






001 102 


Not allowed traffic case 






001 112 


Incompatible traffic case 






01000? 


Requested service not available 






01001? 


Pre-emptive use of resource 






01010? 


Invalid call identifier 






01011? 


Call rejected by the called party 






01100? 


No idle CC entity 






01101? 


Expiry of timer 






011102 


SwMI requested disconnection 






01111? 


Acknowledged service not completed 






100002 


Reserved 






...etc. 


...etc. 






11111? 


Reserved 
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14.8.19 DTMF 

The purpose of the DTMF element shall be to allow the transfer of DTMF digits (n digits where n shall be 
less than or equal to 255) to another user application. 



Table 107: DTMF element contents 



Information element 


Length 


Value 


Remark 


DTMF digit number 1 to n 


n*4 


OOOOp 


Digit "O" 






0001 2 


Digit *T 






001 0 2 


Digit M 2 M 






0011 2 


Digit "3* 






01002 


Digit "4" 






01 01 2 


Digit "5" 






01102 


Digit "6" 






0111? 


Digit *7 M 






10002 


Digit "8 M 






1001 2 


Digit "9" 






10102 


Digit "* u 






10112 


Digit 






11002 


Digit "A" 






11012 


Digit "B" 






11102 


Digit "C" 






11112 


Digit "D" 



14.8.20 External Subscriber Number (ESN) 



The purpose of the ESN element is to allow the transfer of an ESN from a TETRA subscriber to a 
gateway. The ESN can consist of n digits where n shall be less than or equal to 24. 



Table 108: ESN element contents 



Information element 


Length 


Value 


Remark 


External Subscriber Number (ESN) 


n*4 


OOOO2 


Digit a 0 a 


digit number 1 to n 




0001 2 


Digit "1" 






001 0 2 


Digit n 2 M 






0011 2 


Digit m 3* 






01002 


Digit "4" 






01 01 2 


Digit "5 tt 






01102 


Digit "6" 






01112 


Digit "7" 






10002 


Digit "8" 






1001 2 


Digit a 9 tt 






10102 


Digit 






10112 


Digit 






11002 


Digit "A" 






11012 


Digit "B" 






11102 


Digit "C" 






11112 


Digit "D" 
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1 4.8.21 Encryption control 

The purpose of the encryption control element shall be that an MS/LS shall be able to request for 
encryption/clear mode and then be informed about the granting result of this request. 



Table 109: Encryption control element contents 



Information element 


Length 


Value 


Remark 


Encryption control 


1 


0 


clear 






1 


encrypted 



14.8.22 Facility 

The facility element shall be an optional variable length element and shall be used to send and receive SS 
information appended to the PDUs which can carry the facility element. 

The size and the structure of the facility element shall be dependent on each individual SS and shall be 
further detailed in the SS protocol clauses. 



There can be multiple facility elements in the same PDU. 
14.8.23 Hook method selection 

The purpose of the hook method selection element shall be to inform the infrastructure and the called 
user(s) of the preferred hook method. 



Table 110: Hook method selection element contents 



Information element 


Length 


Value 


Remark 


Hook method selection 


1 


0 


No hook signalling (direct through-connect) 






1 


Hook on/Hook off signalling 



14.8.24 Length indicator 

The length Indicator element shall define the length of the user defined data-4. 

Table 111: Length indicator element contents 



Information element 


Length 


Value 


Remark 


Length indicator 


11 


0 


Obits 






1 


1 bit 






...etc. 


...etc. 






(2"-1) 


2 047 bits 



14.8.25 New call identifier 



The new call identifier element coding shall be the same as for the call identifier element. 
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14.8.26 Modify 

The modify element shall be used to change an ongoing call either to a new basic service or the behaviour 
from simplex to duplex or reverse. 



Table 112: Modify element contents 



Information sub-element 


Length 


Value 


Remark 


Simplex/duplex selection 


1 




See description of "Simplex/duplex 
selection" element; 


Basic service information 


8 




See description of "Basic service 
information" element; 



14.8.27 Notification indicator 



The notification indicator element shall be used in SSs by the SwMI to inform a MS/LS of various events. 



Table 113: Notification indicator element contents 



Information element 


Length 


Value 


Remark 


Notification indicator 


6 


0-63m 


Reserved. 



14.8.28 PDUtype 

The purpose of the PDU type element shall be to clearly identify the type of CMCE PDU sent over the air 
interface. The PDU type element shall have separate definitions in the uplink and downlink directions as 
shown in table 114. 



Table 114: PDU type element contents 



Information element 


Length 


Value 


Remark 








Downlink 


Uplink 


PDU Type 


5 


00000 2 


D-ALERT 


U-ALERT 






00001 2 


D-CALL-PROCEEDING 


Reserved 






00010? 


D-CONNECT 


U-CONNECT 






00011 2 


D-CONNECT ACKNOWLEDGE 


Reserved 






00100? 


D-DISCONNECT 


U-DISCONNECT 






00101? 


D-INFO 


U-INFO 






00110? 


D-RELEASE 


U-RELEASE 






00111? 


D-SETUP 


U-SETUP 






010002 


D-STATUS 


U-STATUS 






01 001 2 


D-TX CEASED 


U-TX CEASED 






010102 


D-TX CONTINUE 


U-TX DEMAND 






0101 1 2 


D-TX GRANTED 


Reserved 






011002 


D-TX WAIT 


Reserved 






01101? 


D-TX INTERRUPT 


Reserved 






01110? 


D-CALL-RESTORE 


U-CALL-RESTORE 






01111? 


D-SDS-DATA 


U-SDS-DATA 






10000? 


D-FACILITY 


U-FACILITY 






10001 2 


Reserved 


Reserved 






...etc. 


...etc. 


...etc. 






11111? 


Reserved 


Reserved 



Page 189 

ETS 300 392-2: March 1996 

14.8.29 Poll request 

This poll request element shall be used by the SwMI to request a poll response back from the MS/LS 
when an acknowledged group call has been initiated. 



Table 115: Poll request element contents 



Information element 


Length 


Value 


Remark 


Poll request 


1 


0 


No poll answer requested 






1 


Poll answer requested 



14.8.30 Poll response 

This poll response element shall be used by the MS/LS to respond to a poll request in an acknowledged 
group call from the SwMI. 

Table 116: Poll response element contents 



Information element 


Length 


Value 


Remark 


Poll response 


1 


0 


No poll response 






1 


Poll response 



14.8.31 Poll response addresses 

The purpose of the poll response addresses element shall be to provide the addresses on responding 
group members in an acknowledged group call. 

Table 117: Poll response addresses element contents 



Information element 


Length 


Value 


Remark 


1st TSI address 


48 




For TSI address definition see ETS 300 392-1 
[111, clause 7 


2nd TSI address 


48 






...etc. 


...etc. 






nth TSI address 


48 







1 4.8.32 Poll response number 

The purpose of the poll response number element shall be to provide the number of responding group 
members in an acknowledged group call. 

Table 118: Poll response number element contents 



Information element 


Length 


Value 


Remark 


Number of respondinq group members 


6 


0-63m 
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14.8.33 Poll response percentage 

The purpose of the poll response percentage element shall be to provide the percentage of responding 
group members in an acknowledged group call. 



Table 119: Poll response percentage element contents 



Information element 


Length 


Value 


Remark 


Percentage of responding number 


6 


0 


0% 


of group members 




1 


2% 






...etc. 


...etc. 






50io 


100% 






51 10 


Reserved 






...etc. 


...etc. 






63m 


Reserved 



14.8.34 Pre-coded status 



The purpose of the pre-coded status element shall be to define general purpose status messages known 
to all TETRA systems. 



Table 120: Pre-coded status element contents 



Information element 


Length 


Value 


Remark 


Pre-coded status 


16 


0 


Emergency 






1 


Reserved 






...etc. 


...etc. 






32 767m 


Reserved 






32 768m 


Available for TETRA network and user specific definitions 






...etc. 


...etc. 






65 535io 


Available for TETRA network and user specific definitions 



14.8.35 Proprietary 

Proprietary is an optional, variable length element and shall be used to send and receive proprietary 
defined information appended to the PDUs. The proprietary element is terminated in CMCE. 

The use, the size and the structure of the proprietary element is outside the scope of this ETS. 



1 4.8.36 Request to transmit/send data 

The purpose of the request to transmit/send data element shall be to inform the infrastructure about 
immediate request to transmit or data transmission at through-connection. 



Table 121: Request to transmit/send data element contents 



Information element 


Length 


Value 


Remark 


Request to transmit/send data 


1 


0 


Request to transmit/send data 






1 


Request that other MS/LS may 
transmit/send data; 
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14.8.37 Reset call time-out timer (T310) 

The purpose of the reset call time-out timer element shall be to reset and start the overall call length timer 
T310 in the MS/LS. The timer shall be started with the current value. 



Table 122: Reset call time-out timer element contents 



Information element 


Length 


Value 


Remark 


Reset call time-out value 


1 


0 


No reset of call time-out timer T310 






1 


Reset call time-out timer T310 



1 4.8.38 Short data type identifier 

The purpose of the short data type identifier element shall be to identify the length of the user defined data 
sent to or received from the SwMI. 



Table 123: Short data type identifier element contents 



Information element 


Length 


Value 


Remark 


Short data type identifier 


2 


00? 


User Defined Data 1 element is 16 bits long 






01 2 


User Defined Data 2 element is 32 bits long 






10 2 


User Defined Data 3 element is 64 bits long 






11 2 


User Defined Data 4 element is 0-2047 bits 
long (variable length) 



1 4.8.39 Simplex/duplex selection 

The purpose of the simplex/duplex selection element shall be to inform the infrastructure the preferred 
mode of operation. 



Table 124: Simplex/duplex selection element contents 



Information element 


Length 


Value 


Remark 


Simplex/duplex selection 


1 


0 


Simplex requested 






1 


Duplex requested 



14.8.40 Speech service 

The purpose of the speech service element shall be to change between TETRA standard speech and 
non-TETRA speech. It shall be ignored for data bearer services. 

Table 125: Speech service element contents 



Information element 


Length 


Value 


Remark 


Speech service 


1 


0 


TETRA encoded speech 






1 


7,2 kbit/s unprotected data, note 


NOTE: This service shall carry a non-TETRA encoded speech and channel codinq. 



1 4.8.41 Temporary address 

The temporary address element coding shall be the same as for the SSI element. 
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14.8.42 Transmission grant 

The purpose of the transmission grant element shall be to inform the MS/LS about permission to transmit. 



Table 126: Transmission grant element contents 



Information element 


Length 


Value 


Remark 


Transmission grant 


2 


00? 


Transmission granted 






01? 


Transmission not granted 






10? 


Transmission request queued 






11? 


Transmission granted to another user 



14.8.43 Transmission request permission 



The purpose of the transmission request permission element shall be to inform the MS/LS if it is allowed 
to request for transmit permission. 



Table 127: Transmission request permission element contents 



Information element 


Length 


Value 


Remark 


Transmission request permission 


1 


0 


Allowed to request for transmission 






1 


Not allowed to request for transmission 



1 4.8.44 Transmitting party type identifier 



The purpose of the transmitting party type identifier element coding shall be to indicate the type of address 
which shall follow in the PDU. 



Table 128: Transmitting party type identifier element contents 



Information element 


Length 


Value 


Remark 


Transmitting party type identifier 


2 


00? 


Reserved. 






01 ? 


Short Subscriber Identity (SSI) 






10 ? 


TETRA Subscriber Identity (TSI) 






11? 


Reserved. 



1 4.8.45 Transmitting party extension 

The purpose of the transmitting party extension element shall be to indicate the extended part of the TSI 
address of the transmitting user. 



Table 129: Transmitting party extension element contents 



Information sub-element 


Length 


Value 


Remark 


Country Code 


10 




See ETS 300 392-1 [1 11, clause 7. 


Network Code 


14 




See ETS 300 392-1 [11], clause 7. 



1 4.8.46 Transmitting party SSI 

The purpose of the transmitting party SSI element shall be to indicate the SSI address of the transmitting 
user. 



Table 130: Transmitting party SSI element contents 



Information element 


Length 


Value 


Remark 


Short Subscriber Identity (SSI) 


24 




See ETS 300 392-1 [11], clause 7. 
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14.8.47 TX demand priority 

The purpose of the Tx demand priority element shall be to inform the SwMI about the importance of a TX- 
Demand 



Table 131: Tx demand priority element contents 



Information element 


Length 


Value 


Remark 


TX demand priority 


2 


00 2 


Low priority level 






01 2 


Hiqh priority level 






10 2 


Pre-emptive priority level 






11 2 


Emergency pre-emptive priority level 



1 4.8.48 Type 3 element identifier 

The purpose of the Type 3 element identifier element is to indicate the type of the following Type 3 
element in the PDU. 



Table 132: Type 3 element identifier element contents 



Information element 


Length 


Value 


Remark 


Type 3 element identifier 


4 


0000? 


Reserved 






0001 2 


DTMF 






001 0 2 


External subscriber number 






0011 2 


Facility 






01002 


Poll response addresses 






01 01 2 


Proprietary 






01102 


Reserved for any future specified Type 3 element 






...etc. 


...etc. 






11112 


Reserved for any future specified Type 3 element 



1 4.8.49 User defined data-1 



The User Defined Data-1 element shall enable the user applications to determine their own interpretation 
of the SDS message. 



Table 133: User Defined Data-1 element contents 



Information element 


Length 


Value 


Remark 


User Defined Data-1 


16 


0-(2 io -1) 


All values available for the user application; 



1 4.8.50 User defined data-2 



The User Defined Data-2 element shall enable the user applications to determine their own interpretation 
of the SDS message. 



Table 134: User Defined Data-2 element contents 



Information element 


Length 


Value 


Remark 


User Defined Data-2 


32 


0-(2°'-1) 


All values available for the user application 
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1 4.8.51 User defined data-3 

The User Defined Data-3 element shall enable the user applications to determine their own interpretation 
of the SDS message. 



Table 135: User Defined Data-3 element contents 



Information element 


Length 


Value 


Remark 


User Defined Data-3 


64 


0-(2 o4 -1) 


All values available for the user application 



1 4.8.52 User defined data-4 



The User Defined Data-4 element shall enable the user applications to determine their own interpretation 
of the SDS message. 



Table 136: User Defined Data-4 element contents 



Information element 


Length 


Value 


Remark 


User Defined Data-4 


varies 
(0-2 047 bits) 


varies 


All values available for the user application 



1 5 Mobility Management (MM) service description 



15.1 Introduction 

This clause describes the services offered by the MM entity (see ETS 300 392-1 [11], clause 6) for the 
V+D TETRA layer 3 air interface. The MM SAP is used in conformance testing as a normative boundary in 
TETRA MSs and in TETRA LSs. 

15.2 Services offered 

The MM shall be a service provider for mobility service users on the layer 3 MS air interface. The services 
shall be made available through a TETRA Network Mobility Management Service Access Point (TNMM- 
SAP) (see ETS 300 392-1 [11], clause 6) which is shown in figure 41. The protocol description is defined 
in clause 16. 

The services offered shall be: 

registration: this service shall allow a user to register manually to the network, the user shall be then 
informed of the result of the registration. When a user roams or migrates he shall be also informed 
that the MS is ready for use or that registration was not possible (see ETS 300 392-1 [11], 
clause 9); 

de-registration (detach), this service allows a user to request cancellation of the registration, the 
user shall be informed of the cancellation success; 

change of energy saving mode, this service shall allow the user to ask for changing the energy 
saving mode with confirmation; 

attachment/detachment of group identities, this service shall allow the user application to either 
activate or deactivate already defined group identities in the MS/LS. The service shall also inform 
the user applications of the result of the attachment/detachment of the group identities both when 
the user application initiates the attachment/detachment or when the SwMI initiates the 
attachment/detachment; 

information concerning state of the mobile (enable, disable), this service shall allow a user to be 
aware of the temporary or permanent disabling asked by the network. The user application is also 
made aware of the cessation of a temporary disable. 

A set of primitives shall be offered to implement each of those services. 
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1 5.3 Primitive description 

The services shall be provided through primitives at the TNMM-SAP. This subclause describes the 
primitives and their parameters. 



15.3.1 



Service state model for the MS 



The primitives provided at the TNMM-SAP are illustrated in figure 41 . 



7FT 



SIGNAL L\ 
TNMM -ATTACH DETACH GROUP ID request, 
TNMM -ATTACH DETACH GROUP ID indication, 
TNMM-ATTACH DETACH GROUP ID confirm, 
TNMM-DEREGISTRATION request, 
TNMM-DISABLING indication, 
TNMM-ENABLING indication, 
TNMM-ENERGY SAVING confirm, 
TNMM-ENERGY SAVING request, 
TNMM-REGISTRATION confirm, 
TNMM-REGISTRATION indication, 
TNMM-REGISTRATION request, 
TNMM-REPORT indication, 
TNMM-SERVICE indication; 



TNMM-ATTACH DETACH GROUP ID indication, 
TNMM-ATTACH DETACH GROUP ID confirm, 
TNMM-REPORT indication, 
TNMM-DISABLING indication, 
TNMM-ENABLING indication, 
TNMM-ENERGY SAVING confirm, 
TNMM-REGISTRATION confirm, 
TNMM-REGISTRATION indication, 
TNMM-SERVICE indication; 



TNMM SAP 



TNMM-ATTACH DETACH GROUP ID request, 
TNMM-DEREGISTRATION request, 
TNMM-ENERGY SAVING request, 
TNMM-REGISTRATION request; 



MM SERVICE 
MS 



Figure 41 : Services provided at TNMM-SAP/MS-side 
1 5.3.2 Service primitives at the TNMM-SAP, MS/LS side 

The set of MM primitives that are available to provide the specified service to the user application shall be: 

TNMM-ATTACH DETACH GROUP IDENTITY request/indication/confirm: the primitives shall be used to 
handle activation and deactivation of defined GTSIs in the MS/LS; 

TNMM-DEREGISTRATION request: the primitive shall be used to handle detachment of attached ITSIs; 

TNMM-DISABLING indication: the primitive shall be used when an MS is either temporary or permanently 
disabled; 

TNMM-ENABLING indication: the primitive shall be used when an MS is enabled in order to become 
operational again; 

TNMM-ENERGY SAVING request/confirm: the primitives shall be used to exchange energy saving mode 
of operation to the SwMI; 

TNMM-REGISTRATION request/indication/confirm the primitives shall be used to handle attachment of 
ITSIs and can as well be used for activation/de-activation of GSSIs; 



Page 196 

ETS 300 392-2: March 1996 

TNMM-REPORT indication: the primitive shall be used to inform the user application of a successful or 
unsuccessful transmission of U-ITSI DETACH; 

TNMM-SERVICE indication: the primitive shall be used as an indication to the user application to reflect 
the service state of the MS, i.e. whether it shall be possible to initiate or receive communication using the 
current network. 

1 5.3.3 Primitive description 

The information contained in the primitive description tables which follow corresponds to the following key: 

KEY: M: Mandatory; C: Conditional; O: Optional; -: Not used. 

1 5.3.3.1 TNMM-ATTACH DETACH GROUP IDENTITY primitive 

TNMM-ATTACH DETACH GROUP IDENTITY request primitive shall be used by the user application to 
activate or deactivate one or more defined group identities in the MS/LS. 

TNMM-ATTACH DETACH GROUP IDENTITY indication primitive shall be used an indication to the user 
application when the SwMI has activated or de-activated one or more defined group identities in the 
MS/LS. 

TNMM-ATTACH DETACH GROUP IDENTITY confirm primitive shall be used as an indication to the user, 
that the requested activation or de-activation of group identities is negotiated between the MS/LS and the 
SwMI. 

The parameters shall be defined as follows: 



Table 137: Parameters for the primitive TNMM-ATTACH DETACH GROUP IDENTITY 



Parameter 


Request 


Indication 


Confirm 


Group identity attach detach mode 


M 




M 


Group identity request 


M 






Group identity report 


0 




0 


Group identities 




M 


M 



1 5.3.3.2 TNMM-DEREGISTRATION primitive 

TNMM-DEREGISTRATION request: shall be used to request to cancel the registration, stimulated either 
by removing the "ITSI identity" or a "log-off" application or automatically in the power off phase. 

The parameters shall be defined as follows: 

Table 138: Parameters for the primitive TNMM-DEREGISTRATION 



Parameter 


Request 


MCC 


0 


MNC 


0 



1 5.3.3.3 TNMM-DISABLING primitive 

TNMM-DISABLING indication primitive shall be used as an indication to the user application that a 
temporary or permanent disabling of the terminal is ordered. 

The parameters shall be defined as follows: 



Table 139: Parameters for the primitive TNMM-DISABLING 



Parameter 


Indication 


Disable status 


M 
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1 5.3.3.4 TNMM-ENABLING primitive 

TNMM-ENABLING indication primitive shall be used as an indication to the user application that the 
temporary disabling of the terminal is cancelled. 

The parameters shall be defined as follows: 



Table 140: Parameters for the primitive TNMM-ENABLING 



Parameter 


Indication 


Service status 


M 



1 5.3.3.5 TNMM-ENERGY SAVING primitive 

NOTE: This primitive is present at the TNMM-SAP in a LS but need not be used since a LS is 
normally not battery powered. 

TNMM-ENERGY SAVING request primitive shall be used by the user application to change or re-state to 
the SwMI what energy economy mode the MS wants to use. 

TNMM-ENERGY SAVING confirm primitive shall be used as a confirmation to the user application that the 
changed or re-stated energy economy mode has been reported to the SwMI. 

The parameters shall be defined as follows: 



Table 141 : Parameters for the primitive TNMM-ENERGY SAVING 



Parameter 


Request 


Confirm 


Energy economy mode 


M 


M 


Energy economy mode status 




M 



1 5.3.3.6 TNMM-REPORT primitive 

TNMM-REPORT indication shall be used to inform the user application of a successful or unsuccessful 
transmission of U-ITSI DETACH. 

The parameters shall be defined as follows: 



Table 142: Parameters for the TNMM-REPORT primitive 



Parameter 


Indication 


Transfer result 


M 



1 5.3.3.7 TNMM-REGISTRATION primitive 

TNMM-REGISTRATION request primitive shall be used by the user application to initiate attachment and 
registration of the terminal. 

TNMM-REGISTRATION indication primitive shall be used as an indication to the user application that the 
LS/MS is ready for use (network initiated registration). 

TNMM-REGISTRATION confirm primitive shall be used to inform the user application that registration is 
confirmed. The primitive may be used to inform the user that the MS/LS is ready for use. 
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The parameters shall be defined as follows: 



Table 143: Parameters for the primitive TNMM-REGISTRATION 



Parameter 


Request 


Indication 


Confirm 


Registration Status 


- 


M 


M 


Registration Reject Cause (note 1) 




C 




Registration Type 


M 






LA (note 2) 


C 






MCC (note 3) 


C 






MNC (note 3) 


c 






ISSI 


M 






Group identities 




0 


0 


Group identity request 


0 






Group identity attach/detach mode 


0 


O 


0 


Group identity report 


0 






NOTE 1 : Shall be present if Registration Status = "failure". 
NOTE 2: Shall be present if Registration Type = "No new ITSI - forward 
registration". 

NOTE 3: Shall be present if Registration Type - "New ITSI"; or 

Registration Type = "No new ITSI - forward registration". 



1 5.3.3.8 TNMM-SERVICE primitive 

TNMM-SERVICE indication primitive shall be used as an indication to the user application to reflect the 
service state of the MS, i.e. whether it shall be possible to initiate or receive communication using the 
current network. 

The parameters shall be defined as follows: 



Table 144: Parameters for the primitive TNMM-SERVICE 



Parameter 


Indication 


Service status 


M 


Disable status 


M 



1 5.3.4 Parameters description 

Parameters shall be part of the primitives described in subclause 15.3.3 and if applied the parameters 
shall contain the values specified in this subclause. 

Class of usage = 

Class of Usage 1 ; 
Class of Usage 2; 
Class of Usage 3; 
Class of Usage 4; 
Class of Usage 5; 
Class of Usage 6; 
Class of Usage 7; 
Class of Usage 8. 

Disable status = 

enabled; 

temporary disabled; 
permanently disabled. 



Page 199 
ETS 300 392-2: March 1996 



Energy economy mode = 
stay alive; 

energy economy mode 1 ; 
energy economy mode 2; 
energy economy mode 3; 
energy economy mode 4; 
energy economy mode 5; 
energy economy mode 6; 
energy economy mode 7. 

Energy economy mode status = 

accepted; 
rejected. 

Group identities = 

Table 145: Group identities parameter 



Parameter 


C/O/M 


Remark 


GTSI 


M 




Group Identity Type Identifier 


M 




Group Identity Lifetime 


C 


note 


Class of Usage 


C 


note 


Group Identity Detachment 


C 


note 


NOTE: Shall be conditional on the value of Group Identity Type 
Identifier (GITI). 

GITI = Attachment; Group Identity Lifetime + Class of Usage; 
GITI = Detachment; Group Identity Detachment. 



Group identity attach/detach mode = 
amendment; 

detach the currently active group identities. 
Group identity request = 

Table 146: Group identity request parameter 



Parameter 


C/O/M 


Remark 


GTSI 


M 




Group Identity Type Identifier 


M 




Class of Usage 


C 


note 


Group Identity Detachment Request 


C 


note 


NOTE: Shall be conditional on the value of Group Identity Type 


Identifier (GITI). 






GITI = Attachment; Class of Usage; 




GITI = Detachment; Group Identity Detachment. 



Group identity type identifier = 

attachment; 
detachment. 

Group identity lifetime = 

permanent, attachment not needed; 
permanent, attachment needed; 
session based, attachment not allowed. 



Page 200 

ETS 300 392-2: March 1996 

Group identity detachment = 

permanently detached; 
session based detached; 
temporary detached; 
unknown group identity. 

Group identity detachment request = 

unknown group identity; 
user initiated detachment. 

Group identity report = 

report requested; 
report not requested. 

GTSI = 

Group TETRA Subscriber Identity. 

ISSI = 

Individual Short Subscriber Identity; 
LA. 

MCC = 

Mobile Country Code (see 300 392-1 [11], clause 7). 
MNC = 

MNC (see 300 392-1 [11], clause 7). 

Registration reject cause = 

ITSI unknown; 

illegal MS; 

LA not allowed; 

LA unknown; 

network failure; 

congestion; 

service not supported; 

service not subscribed; 

mandatory element error; 

message consistency error; 

roaming not supported; 

migration not supported; 

no cipher KSG; 

identified cipher KSG not supported; 
requested cipher key type not available; 
identified cipher key not available; 
incompatible service. 

Registration status = 

success; 
failure. 
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Registration type = 

no new ITSI - periodic registration; 
no new ITS! - forward registration, 
new ITSI 

Service status = 

in service; 

in service waiting for registration; 
out of service. 

Transfer result = 

transfer successful done; 
transfer fail. 

15.3.5 State description for the MS 

The following subclauses define the status of the different states used within the SDL description given in 
subclause 15.3.6. 

15.3.5.1 Not updated 

This state shall be used when the MS is ready for a registration request. 

15.3.5.2 Wait updating 

This shall be an intermediate state while the network is processing the registration request. 

15.3.5.3 Updated 

This shall be the state that is used while registered. The MS shall be ready for transactions 

1 5.3.5.4 Temporary disabled 

This state shall be used after receiving a <disable> message with parameter "temporary". The only way 
out of the state shall be a <enable> message. 

1 5.3.5.5 Permanently disabled 

This state shall be used after receiving a <disable> message with parameter "permanently". There shall 
be no way out of the state using the air interface protocol as defined in this ETS. 
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15.3.6 Service state diagram for the TNMM-SAP 

The service state diagram for the TNMM-SAP shall be as shown as follows: 
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Figure 42: MM service state diagram (sheet 1 of 4) 
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Figure 43: MM service state diagram (sheet 2 of 4) 
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Figure 44: MM service state diagram (sheet 3 of 4) 
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Figure 45: MM service state diagram (sheet 4 of 4) 



16 MM protocol 
16.1 Introduction 

This clause defines for the MS the TETRA MM protocol. This is the network layer protocol that shall be 
used to provide the MM service (see clause 15). This clause defines the protocol functions required for 
operation as an end system (i.e. providing service to an end user). 



This clause specifies: 



procedures for registration of a MS; 

procedures for disabling and enabling of a MS; 

procedures for negotiating the energy saving scheme to be used; 

procedures for attachment/detachment of group identities. 
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The procedures are defined in terms of: 

interactions among peer network entities through the exchange of PDUs; 

interactions between a network entity and a network service user through the exchange of network 
service primitives; 

interaction between a network entity and an underlying service provider through the exchange of 
service primitives. 

16.2 MM procedures 

16.2.1 Genera! 

The internal organisation of the network layer including the MM entity is described in the V+D protocol 
architecture's (see ETS 300 392-1 [11], clause 6). 

The underlying services offered are those of the MLE, refer to clause 17 and ETS 300 392-1 [11], 
clause 1 4. 

16.2.2 Services provided by the protocol 

The following services offered have been described in detail in clause 15: 
registration on user demand; 
enabling and disabling indication; 
de-registration due to user request; 
energy saving mode change to user request; 
attachment/detachment of group identities by user request; 
attachment/detachment of group identities indication. 

16.2.3 Underlying services assumed by the protocol 

On the air interface the protocol shall use the MLE as defined in clause 17. The data transferring type 
when sending MLE-UNITDATA request shall be type "acknowledged" if not defined otherwise in this 
clause. 

1 6.2.4 Services assumed from the local environment 

No specific service shall be assumed from the Lower Layer Management Entity (LLME). 

1 6.3 Protocol functions 

The basic functions of the protocol for the MS shall be: 
to initiate PDU composition and decomposition; 
to initiate header error detection; 

to initiate activation of the selection of a cell sent to the MLE through an MLE-ACTIVATE request 
primitive at power up; 

to initiate a network code check from the information passed by the MLE using an MLE-LINK 
indication primitive. If a LA is a new LA, then registration may be required to be initiated by the MM 
through sending a U-LOCATION UPDATE DEMAND PDU to the infrastructure. If a network code is 
a new one then registration shall be initiated by the MM. The network may accept or reject the 
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registration and the MM shall be informed by receiving a D-LOCATION UPDATE 
ACCEPT/REJECT; 

to update the MLE with a new registration area through an MLE-UPDATE request primitive; 

to initiate handling of exceptional procedures reported by the MLE (failures to requests); 

to supply or update the SSI (ASSI or ISSI) to be used to the MLE. This information shall be in the 
D-LOCATION UPDATE ACCEPT PDU received by the MM; 

to supply or update the complete list of GSSIs to be used to the MLE. This information shall be 
either in the D-LOCATION UPDATE ACCEPT, D-ATTACH/DETACH GROUP IDENTITY or 
D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU received by the MM; 

to send and receive PDUs to and/or from the sub-layer MLE through MLE-UNITDATA request and 
indication primitive. The received PDUs can be handled locally by the MM or routed to the user 
application; 

to send and receive PDUs to and/or from the sub-layer MLE through MLE-PREPARE request and 
indication; 

to initiate the update criteria with the monitoring of other possible cells using an MLE-UPDATE 
request primitive following an infrastructure request; 

to initiate detach handling through a TNMM DEREGISTRATION request from the user, the MM 
shall then send a message to the infrastructure; 

to initiate energy saving mode handling following a change requested by the user, the new value 
may be negotiated by the MM through transmitting it to the network in a energy saving element; 

to enable/disable handling following a request from the infrastructure which shall be transmitted to 
the user by the MM through a TNMM-ENABLING/DISABLING indication primitive. 

On the infrastructure side, the MM functions should be symmetrical, except activation of the selection of a 
cell which does not exist. Figure 46 summarises the MM functions. 

The different protocol procedures are shown in this ETS by the primitive sequences and PDU exchanges. 
The scenarios outlined are: 

enable/disable; 

de-registration; 

energy mode change; 

user request registration; 

network request registration; 

MLE initiated registration; 

user request attachment/detachment of group identities; 
network request attachment/detachment of group identities. 
Figure 46 indicates the main functions of the MM. 
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Figure 46: MM main functions on the MS 
16.3.1 Activation and control of underlying MLE Service 
1 6.3.1 .1 Activation procedure 

If the MS has been permanently disabled the MS shall remain disabled at power up and shall not activate 
any of the protocol entities. The following describes the procedure for MSs that have not been 
permanently disabled. 
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Figure 47: MM Activation procedure, registration not supported 

At power on, or similar start up, the MM shall issue an MLE-ACTIVATE request primitive. The 
MLE-ACTIVATE request primitive shall contain a list of valid mobile network identities. 

When the MS performs cell re-selection, the reception of an MLE-ACTIVATE indication shall indicate that 
no suitable cell has been found by the MLE. The MM entity may issue a new MLE-ACTIVATE request 
primitive with a revised list of cell selection parameters. If no new parameters are available MM shall then 
inform the user application with a TNMM-SERVICE indication primitive issuing that the MS is "out of 
service". 



Either at initial activation or after a new activation due to cell re-selection, MM shall await the receipt of an 
MLE-ACTIVATE confirm which indicates whether MLE has successfully selected a cell. 

Upon receipt of an MLE-ACTIVATE confirm primitive, the MM entity shall check whether the selected cell 
requires registration as follows: 

a) registration mandatory: 

the MM shall inform the user application with TNMM-SERVICE indication issuing that the MS 
is "in service waiting for registration"; 



b) registration is not required: 
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the MM shall open the communication resources to the other higher layer entities by issuing 
an MLE-OPEN request primitive. This MLE-OPEN request primitive shall be accompanied by 
a list of currently valid subscriber identities in an MLE-IDENTITIES request primitive. The MM 
shall inform the user application with TNMM-SERVICE indication indicating that the MS is "in 
service". The MLE-OPEN request shall not be issued if the MS has previously been 
temporarily disabled and not subsequently enabled by the infrastructure. 

1 6.3.1 .2 Deactivation procedure 

This procedure shall be invoked at power down or if the ITSI is detached from the MS. The MM shall issue 
an MLE-CLOSE request to indicate that access to the communication resources has been closed to the 
other higher layer entities; CONP, SCLNP and CMCE. MM shall then issue an MLE-DEACTIVATE 
request primitive. 

1 6.3.1 .3 Maintenance procedures 

1 6.3.1 .3.1 Report and cancel handling 

The cancel and report procedure may be implemented in the MS and if used the following shall apply. 

Incoming MLE-REPORT indications should indicate the following events: 

a PDU has been stored by the DLL ready for transmission. At this stage the transmission may be 
cancelled using a MLE-CANCEL request and no information will be sent over the air interface; 

the first transmission of whole PDU. The BS may have received the PDU, but MS has not yet 
received an acknowledgement. At this stage the layer 2 process may be stopped using a 
MLE-CANCEL request, but MM cannot rely on the cancellation and may receive a response to the 
sent PDU; 

a PDU has not been successfully transmitted by layer 2 Cancellation is no longer possible, but the 
BS may have received the PDU correctly and MM cannot rely on the cancellation and may receive a 
response to the sent PDU; 

a PDU has been successfully transmitted by layer 2. Cancellation is no longer possible. 

The MLE-CANCEL request can minimise the risk of adding extra load to the air interface, e.g. when a 
user application initiated registration request is buffered by the lower layers waiting for allowance to make 
random access attempt, which can take a considerable amount of time. If the user application during this 
waiting period changes its decision and wants to de-register, the application shall send a 
TNMM-DEREGISTRATION request which will be converted to a MLE-CANCEL request depending on the 
status of the transmission as stated above. 

16.3.1.3.2 Stealing permission and stealing repeats flag handling 

For each PDU sent by MM, stealing permission and stealing repeats flag are set to some value. The 
values used are outside of the scope of this ETS. 

1 6.3.1 .3.3 Busy handling 

MLE-BUSY request shall be sent to the MLE by the MM when it initiates individually addressed signalling 
exchange with the SwMI, e.g. registration, and MLE-IDLE request shall be sent to the MLE when the MM 
has completed that signalling preventing the MLE from accepting group-addressed channel change while 
individual signalling is in progress. 

1 6.4 Registration procedure 

The registration procedures are illustrated in figure 48 to figure 51 respectively. Registration can be 
initiated by the MLE, by the user application or it can be requested by the infrastructure. 
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16.4.1 MLE initiated registration procedure 

The MLE shall initiate registration when cell re-selection into a different registration area is indicated from 
the MLE. Cell re-selection into a LA that is in a different registration area shall be notified to MM by the 
receipt of an MLE-LINK indication primitive. The MLE-LINK indication shall supply the MNC and the MCC 
of the new cell. 



If the MCC and MNC differ from the currently registered network and are the same as a home network 
MCC and MNC, the registration procedure described in subclause 16.4.2 b) and the new ITSI applies. 

The registration procedure type can be either normal or forward registration indicated by forward 
registration parameter received in the MLE-LINK indication from the MLE. 



16.4.1.1 



Normal registration 



The registration procedure can be carried out with, or without, identity exchange (see ETS 300 392-1 [11], 
clause 9). Identity exchange shall be required where the MS migrates to a new TETRA network other than 
the home network. 
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NOTE: MLE-REPORT shown in this figure applies to all scenarios where MM sends a PDU. 
Figure 48: MLE initiated registration without identity exchange in the home network 



a) Roaming: 

the MM entity shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with an 
MLE-UNITDATA request primitive. The location update type element in the PDU shall be set 
either to "roaming location updating", or if there was a circuit mode call active, to "call 
restoration roaming location updating". If "roaming location updating" PDU priority is set to 3 
and if "call restoration roaming location updating" PDU priority is set to 5, then the PDU 
includes request for attachment/detachment of group identities in the group identity location 
update element. The PDU may also contain any energy economy mode information. The 
primitive parameters shall indicate which address shall be appended by the lower layers, 
either ISSI or ASSI. Timer T351 shall be started; 



b) Migrating: 

the MM entity shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with an 
MLE-UNITDATA request primitive. The location update type element in the PDU shall be set either 
to "migrating location updating", or if there was a circuit mode call active, to "call restoration 
migrating location updating". If "migrating location updating* PDU priority shall be set to 3 and if "call 
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restoration migrating location updating" PDU priority shall be set to 5, the PDU may include the 
MNC and MCC of the home network of the MS, i.e. those corresponding to the ITSI. The PDU may 
set the LACC to the MCC of the new cell and the LANC to the MNC of the new cell. The PDU may 
also contain the class of MS and may contain any energy economy mode information. Finally the 
PDU may include request for attachment/detachment of group identities in the group identity 
location update element. The primitive parameters shall indicate to the lower layers that the address 
to be appended shall be the USSi. Timer T351 shall be started. 

Upon receipt of the D-LOCATION UPDATE PROCEEDING, the MM shall extract the (V)ASSI from the 
SSI field and send this to the MLE by using MLE-IDENTITIES request primitive. Timer T351 shall be 
stopped and reset. 

As the message is a response to a request made using the USSI, MM shall check whether the MCC and 
the MNC, if included, correspond to those values held in the MS. This shall be used to ensure that if two 
mobiles requests registrations using the same USSI that MM can distinguish between them. If the MCC 
and the MNC does not correspond the transmitted values, the MM shall re-try U-LOCATION UPDATE 
DEMAND PDU sending as described above. The MM entity shall reply with a second 
U-LOCATION UPDATE DEMAND PDU containing the full ITSI and any attached GTSI to the MLE with an 
MLE-UNITDATA request primitive. This shall have PDU priority 6. The location update type element in the 
PDU shall be set to demand location updating. The primitive parameters shall indicate that the address to 
be appended by the MAC shall be the SSI ((V)ASSI). Timer T351 shall be started. 

For a) and b) the following shall apply: 

upon receipt of the D-LOCATION UPDATE ACCEPT PDU, which shall be received with an 
MLE-UNITDATA indication, the MM shall extract the ASSI or (V)ASSI from the SSI field. 
Additionally the MM shall extract attached/detached GSSIs and/or associated (V)GSSIs from the 
group identity location accept element, if present; 

MM shall inform the MLE of ASSI or (V)ASSI and valid group identities, see subclause 16.8, with an 
MLE-IDENTITIES request primitive; 

Timer T351 shall be stopped and reset; 

MM shall extract from the PDU the information concerning SCCHs, energy economy mode, 
subscriber class and minimum mode (18th frame) monitoring, and inform these to the lower layers 
in an MLE-INFO request primitive; 

the MS MM shall issue an MLE-UPDATE request primitive confirming the cell. MM shall inform the 
user application that the MS is ready for use by issuing a TNMM-REGISTRATION indication 
primitive containing attached/detached GTSIs; 

where an energy economy mode has been requested and the MS is not informed of the outcome of 
this request in the D-LOCATION UPDATE ACCEPT PDU, the information shall be conveyed in a 
separate D-ENERGY SAVING PDU as described in subclause 16.7; 

upon receipt of a D-LOCATION UPDATE REJECT, the MM shall analyse the reject cause; 

timer T351 shall be stopped and reset; 

in the event that a mandatory element error or message inconsistency error is reported, the MS 
shall be allowed one registration re-try; 

in the event that a ITSI unknown is reported and the SSI address used in the MAC were ASSI, the 
MS shall be allowed one registration re-try. In this case the address to be appended by the MAC 
shall be ASSI and the ISSI shall be included into the PDU; 

in the event that one of the ciphering key reject causes is reported, the MS shall follow cipher 
negotiation procedures which are outside the scope of this clause of the ETS. For all other reject 
reasons, and where the registration re-try has resulted in a second D-LOCATION UPDATE 
REJECT being received, then MM shall issue an MLE-UPDATE request primitive with a revised list 
of cell selection parameters in order that the MLE does not select the same cell a second time; 
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further registration requests can be made once a new cell has been selected; 

in the event that the serving cell was the only cell available MM shall issue an MLE-CLOSE request 
to the MLE and TNMM-SERVICE indication to the TNMM-SAP indicating that the MS is "out of 
service". The MM shall consider the MS to be de-registered and hence apply the activation 
procedure as defined in subclause 16.3 in order to get into service again. 

NOTE: When to apply the activation procedure, after no service is obtained, is outside the 
scope of this ETS. 



16.4.1.2 
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Figure 49: MLE initiated forward registration 



If the MCC and MNC parameters in the MLE-LINK indication equals to the currently active LSs, LACC and 
LANC, the location update type element in the PDU shall be set to "call restoration roaming location 
updating". 

If the MCC and MNC parameters in the MLE-LINK indication differs from the currently active LA, LACC 
and LANC, the location update type element in the PDU shall be set to "call restoration migrating location 
updating". The PDU shall set the LACC to the MCC of the new cell and the LANC to the MNC of the new 
cell. The requested LA shall be appended to the current LA by setting the "request to append location 
area" field accordingly. 

The PDU shall also contain any energy economy mode information. Finally the PDU may include request 
for attachment/detachment of group identities in the group identity location update element. Timer T351 
shall be started. MM entity shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with an 
MLE-PREPARE request primitive. PDU priority shall be set to 6. 

Upon receipt of the D-LOCATION UPDATE ACCEPT by the MLE-PREPARE confirm. The MM shall 
extract the ASSI or (V)ASSI from the SSI field. Additionally the MM shall extract attached/detached GSSIs 
and/or associated (V)GSSIs from the group identity location accept element, if present. MM shall inform 
the MLE of ASSi or (V)ASSI and valid group identities, (see definition of valid group identities in 
attachment/detachment of group identities, subclause 16.8) with an MLE-IDENTITIES request primitive. 

Timer T351 shall be stopped and reset. MM shall extract from the PDU the information concerning SCCH, 
energy economy mode, subscriber class and minimum mode (18th frame) monitoring, if present, and 
inform these to the lower layers in an MLE-INFO request primitive. 

The MS MM shall issue an MLE-UPDATE request primitive confirming the cell. MM shall inform the user 
application that the MS is ready for use by issuing a TNMM-REGISTRATION indication primitive 
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containing attached/detached GTSIs. Where an energy economy mode has been requested and the MS 
is not informed of the outcome of this request in the D-LOCATION UPDATE ACCEPT PDU, the 
information shall be conveyed in a separate D-ENERGY SAVING PDU as described in subclause 16.7. 

Upon receipt of a D-LOCATION UPDATE REJECT. PDU received by the MLE-PREPARE confirm, the 
MM shall analyse the reject cause. 



Timer T351 shall be stopped and reset. 



In the event that a mandatory element error or message inconsistency error is reported, the MS shall be 
allowed one registration re-try. 

In the event that a ITSI unknown is reported and the SSI address used in the MAC were ASSI, the MS 
shall be allowed one registration re-try. Then the address to be appended by the MAC shall be ASSI and 
the ISSI shall be included into the PDU. 



In the event that one of the ciphering key reject causes is reported, the MS shall follow cipher negotiation 
procedures which are outside the scope of this ETS. For all other reject reasons, and where the 
registration re-try has resulted in a second D-LOCATION UPDATE REJECT being received, then MM 
may stay registered on the current serving cell and shall not be allowed to forward register to the rejected 
cell. New forward registration can be made once a new cell has been selected or once the MS has 
roamed or migrated to another cell. 



16.4.2 



User application initiated registration procedure 



User application initiated registration shall be available whenever the MS is camped on a cell, i.e. has 
received TNMM-SERVICE indication stating that the MS is "in service waiting for registration". It shall be 
applied whenever an identity is attached to the MS, e.g. by inserting a SIM card. The user application 
initiated registration can be used at power up, at any time provided that an ITSI is available either within 
the MS, or can be supplied with the TNMM-REGISTRATION request primitive. 
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Figure 50: User application initiated registration in the home network, 
communication resources closed 

Upon receipt of a TNMM-REGISTRATION request primitive from the user application the MS MM shall 
ascertain whether there is a new ITSI being attached as follows: 

a) no new ITSI: 

MM shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with an MLE-UNITDATA 
request primitive. This shall have PDU priority 0; 
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if the user application is not requesting forward registration to a new system, the location 
update type element in the PDU shall be set to "periodic location updating". If the user 
application is requesting forward registration to a new system, the location update type 
element in the PDU shall be set to "migration location updating", or if there was a circuit 
mode call active, to "call restoration migration updating". For the latter two values the PDU 
priority shall be set to 3. The PDU shall set the LACC to the MCC of the new cell and the 
LANC to the MNC of the new cell. The PDU shall include the LACC and the LANC. The 
requested LA shall be appended to the current LA by setting the "request to append location 
area" field accordingly. The PDU shall also contain the class of mobile and any energy 
economy mode information. Finally the PDU may include request for attachment/detachment 
of group identities in the group identity location update element. The primitive parameters 
shall indicate that the address to be appended by the MAC shall be the SSI (ISSI or ASSI). 
Timer T351 shall be started. 

b) new ITS I: 

the MM shall register with the home network using ISSI. MM shall send a U-LOCATION 
UPDATE DEMAND PDU to the MLE with an MLE-UNITDATA request primitive. This shall 
have PDU priority 6. The location update type element in the PDU shall be set to "ITSI 
attach". The PDU shall also contain the class of mobile and any energy economy mode 
information. Finally the PDU may include request for attachment/detachment of group 
identities in the group identity location update element. The primitive parameters shall 
indicate that the address to be appended by the MAC shall be the SSI (ISSI). Timer T351 
shall be started; 

c) new un-exchanged ITSI: 

the MM shall be required to register on a visited network using identity exchange. The MM 
entity shall send a U-LOCATION UPDATE DEMAND PDU to the MLE with an 
MLE-UNITDATA request primitive. This shall have PDU priority 3. The location update type 
element in the PDU shall be set to "ITSI attach". The PDU may include the MNC and MCC of 
the home network of the MS, i.e. those corresponding to the ITSI. The PDU may also contain 
the class of mobile and any economy mode information. Finally the PDU may include request 
for attachment/detachment of group identities in the group identity location update element. 
The primitive parameters shall indicate to the lower layers that the address to be appended 
shall be the USSI. Timer T351 shall be started. 

Upon receipt of the D-LOCATION UPDATE PROCEEDING PDU, the MM shall extract the (V)ASSI from 
the SSI field and send this to the MLE by using MLE-IDENTITIES request primitive. 

Timer T351 shall be stopped and reset. 

As the message is a response to a request made using the USSI, MM shall check that the MCC and the 
MNC, if included, correspond to those values held in the MS. This shall be used to ensure that if two 
mobiles requests registrations using the same USSI that MM can distinguish between them. 

If the MCC and the MNC do not correspond the transmitted values, the MM shall re-try 
U-LOCATION UPDATE DEMAND PDU sending as described above. The MM entity shall reply with a 
second U-LOCATION UPDATE DEMAND PDU containing the MCC, MNC and ISSI, thus comprising the 
full ITSI to the MLE with an MLE-UNITDATA request primitive. This shall have PDU priority 6. The location 
update type element in the PDU shall be set to "demand location updating". The primitive parameters shall 
indicate that the address to be appended by the MAC shall be the SSI ((V)ASSI). Timer T351 shall be 
started. 

For a), b) and c) the following shall apply: 

upon receipt of the D-LOCATION UPDATE ACCEPT PDU, which shall be received with an 
MLE-UNITDATA confirm primitive, timer T351 shall be stopped and reset. MM shall extract 
any ASSI or (V)ASSI from the SSI field. Additionally the MM shall extract attached/detached 
and GSSls and/or associated (V)GSSIs from the group identity location accept element, if 
present. MM shall inform the MLE of ASSI or V(ASSI) and valid group identities, see 
subclause 16.8, with an MLE-IDENTITIES request primitive. MM shall extract from the PDU 
the information concerning SCCHs, energy economy mode, subscriber class and minimum 
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mode (18th frame) monitoring and inform these to the lower layers in an MLE-INFO request 
primitive. The MS MM shall issue an MLE-UPDATE request primitive confirming the cell. MM 
shall inform the user application that the MS is ready for use by issuing a 
TNMM-REGISTRATION confirm primitive containing attached/detached GTSIs. Where an 
energy economy mode has been requested and the MS is not informed of the outcome of 
this request in the D-LOCATION UPDATE ACCEPT PDU, the information shall be conveyed 
in a separate D-ENERGY SAVING PDU as described in subclause 16.7; 

if registration is successful and communication resources are closed, then the MM shall open 
the communication resources to the other higher layer entities by issuing an MLE-OPEN 
request primitive. The MLE-OPEN request shall not be issued if the MS has previously been 
temporarily disabled and not subsequently enabled by the infrastructure. The MM shall inform 
the user application with TNMM-SERVICE indication issuing that the MS is in service; 

upon receipt of a D-LOCATION UPDATE REJECT the MM shall analyse the reject cause. 
Timer T351 shall be stopped and reset; 

in the event that a mandatory element error or message inconsistency error is reported, the 
MS shall be allowed one registration re-try; 

in the event that a ITSI unknown is reported and the SSI address used in the MAC were 
ASSI, the MS shall be allowed one registration re-try. In this case the address to be 
appended by the MAC shall be ASSI and the ISSI shall be included into the PDU; 

in the event that one of the ciphering key reject causes is reported, the MS shall follow cipher 
negotiation procedures which are outside the scope of this clause of the ETS; 

for all other reject reasons, and where the registration re-try has resulted in a second D- 
LOCATION UPDATE REJECT being received, MM shall issue a TNMM-REGISTRATION 
indication to the user application with the reject cause as a parameter. MM shall issue an 
MLE-UPDATE request primitive with a revised list of cell selection parameters in order that 
the MLE does not select the same cell a second time; 

further registration requests can be made in response to the receipt of further TNMM- 
REGISTRATION requests from the user application, once a new cell has been selected. In 
the event that the serving cell was the only cell available, MM shall issue an MLE-CLOSE 
request to the MLE and TNMM-SERVICE indication to the TNMM-SAP indicating that the MS 
is "out of service". The MM shall consider the MS to be de-registered and hence apply the 
activation procedure as defined in subclause 16.3 in order to get into service again. 

NOTE: When to apply the activation procedure, after no service is obtained is outside the 
scope of this ETS. 
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16.4.3 
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NOTE: Infrastructure initiated registration is carried out following information given by the MLE 
through an MLE-UNITDATA indication. 

Figure 51: Infrastructure initiated registration 

Upon receipt of a D-LOCATION UPDATE COMMAND PDU, the MS MM shall send a 
U-LOCATION UPDATE DEMAND PDU containing the MCC, MNC and ISSI, thus comprising the full ITSI, 
to the MLE with an MLE-UNITDATA request primitive. This shall have PDU priority 6. The location update 
type element in the PDU shall be set to demand location updating or disabled MS updating depending 
whether the MS is enabled or disabled. The primitive parameters shall indicate that the address to be 
appended by the MAC shall be the ASSI, if one has been issued, or the ISSI in the case where an ASSI 
has not been issued. If the group identity report were requested by the infrastructure, then the MM shall 
also send all its active group identities within the PDU in the group identity location update ack element 
and the MS shall not request a group identity report. Timer T351 shall be started. 



Upon receipt of the D-LOCATION UPDATE ACCEPT PDU, the MM shall extract any ASSI or (V)ASSI 
from the SSI field. Additionally the MM shall extract attached/detached GSSIs and/or associated (V)GSSIs 
from the group identity location accept element, if present. MM shall inform the MLE of ASSI or V(ASSI) 
and valid active group identities, see subclause 16.8, with an MLE-IDENTITIES request primitive. Timer 
T351 shall be stopped and reset. MM shall, if elements are present, extract from the PDU the information 
concerning SCCHs, subscriber class and minimum mode (18th frame) monitoring and inform these to the 
lower layers in an MLE-INFO request primitive. MM shall inform the user application about infrastructure 
initiated registration by issuing a TNMM-REGISTRATION indication primitive containing 
attached/detached GTSIs. 



if a D-LOCATION UPDATE REJECT is received, the MM shall analyse the reject cause. In the event that 
a mandatory element error or message consistency error is reported, the MS shall be allowed one 
registration re-try. In the event that one of the ciphering key reject causes is reported, the MS shall follow 
cipher negotiation procedures. 

NOTE 1 : Cipher negotiation procedures are outside the scope of this ETS. 

For all other reject reasons, and where the registration re-try has resulted in a second 
D-LOCATION UPDATE REJECT being received, MM shall issue a TNMM-REGISTRATION indication to 
the user application with the reject cause as a parameter. Timer T351 shall be stopped and reset. MM 
shall issue an MLE-UPDATE request primitive with a revised list of cell selection parameters in order that 
the MLE does not select the same cell a second time. Further registration requests can be made once a 
new cell has been selected. 
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In the event that the serving cell was the only cell available, MM shall issue an MLE-CLOSE request to the 
MLE and TNMM-SERVICE indication to the TNMM-SAP indicating that the MS is "out of service". The MM 
shall consider the MS to be de-registered and hence apply the activation procedure as defined in 
subclause 16.3 in order to get into service again. 

NOTE 2: When to apply the activation procedure after no service is obtained is outside the 
scope of this ETS. 



1 6.4.4 Colliding registrations 

In the event that the MS MM requests registration at the same time that the infrastructure demands that 
the MS MM registers, the MS MM should respond to the D-LOCATION UPDATE COMMAND PDU using 
the procedure defined in subclause 16.4.3. On successful outcome, MM shall inform the user application 
with a TNMM-REGISTRATION indication. 



1 6.4.5 Expiry of timer T351 



On the expiry of timer T351, if it is still possible to solely cancel the outstanding PDU according to 
subclause 16.3.1.3, MM shall issue an MLE-CANCEL request with the handle of the transmission request 
it corresponds to. 

If it is no longer possible to solely cancel the outstanding PDU according to subclause 16.3.1.3, MM shall 
issue a U-ITSI DETACH PDU using the de-registration procedures described in subclause 16.6. 

The MS may wish to select a new serving cell before further registration attempts should be made. 



16.5 Enable and disable procedures 



This procedure shall be initiated from the infrastructure to enable and disable temporarily or permanently a 
MS. The disable procedure is illustrated in figure 52 and the enable procedure is illustrated in figure 53. 
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Figure 52: Disabling of MS 

Upon receipt of a D-DISABLE PDU in an MLE-UNITDATA indication MM shall check the TEI, the MCC 
and the MNC in the PDU. The MS may at this point use the network authentication procedure. 

NOTE 1 : The authentication procedure is outside the scope of this ETS. 

If the TEI in the PDU corresponds to the TEI held in the MS, the MNC and MCC corresponds to those of a 
network that the MS is currently registered on, and the authentication, if applied, were successful, the MM 
shall determine whether the disabling is to be temporary or permanent. The MM shall issue an 
MLE-CLOSE request primitive to indicate that access to the communication resources has been closed. 
The MM shall inform the user application using a TNMM-DISABLE indication that the MS is disabled and 
whether the disabling is temporary or permanent. 

If the TEI in the PDU does not corresponds to the TEI held in the MS, or, the MNC and MCC do not 
correspond to those of a network that the MS is currently registered on, or the authentication were 
unsuccessful, the disable message shall be ignored. 
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If the disabling is permanent the MLE deactivation procedure defined in subclause 16.3.1.2. shall be 
invoked. If the disabling is permanent the whole MS shall remain disabled until an action is taken to 
enable it. 



NOTE 2: The nature of this enable action is outside the scope of this ETS. 

If the disabling is temporary the MS shall remain disabled in the sense that access to the communication 
resources shall remain closed for the CMCE, CONP and SCLNP entities. MM should remain active so that 
any roaming functions can be carried out in order that the MS can receive an enable instruction later. 
Should the MS be powered down the MS shall retain the information that it is temporarily disabled. 
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Figure 53: Enabling of MS 



Upon receipt of a D-ENABLE PDU in an MLE-UNITDATA indication, MM shall check TEI, the MCC and 
the MNC in the PDU. If the TEI in the PDU corresponds to the TEI held in the MS and the MNC and MCC 
corresponds to those of a network that the MS is currently registered on, the MM shall inform the user 
application using a TNMM-ENABLE indication that the MS is now enabled. The MM shall issue an 
MLE-OPEN request primitive to indicate that access to the communication resources has now been 
opened. If the TEI in the PDU does not correspond to the TEI held in the MS, or, the MCC and MNC do 
not corresponds to those of a network that the MS is currently registered on, the enable message shall be 
ignored. 

16.6 De-registration procedure 

The de-registration procedure need not be applied. Examples of where the user application may request 
de-registration can be at power down, or if the user specific information, including the ITSI, is removed 
from the TE. 
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Figure 54: De registration of MS (Detach) 

Upon receipt of a TNMM-DEREGISTRATION request primitive from the user application the MS MM shall 
send a U-ITSI DETACH PDU to the MLE with an MLE-UNITDATA request primitive. This shall have PDU 
priority 3. 
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Upon receipt of the MLE-REPORT indication indicating that the U-ITSI DETACH PDU has been 
successfully or unsuccessfully transmitted by the DLL, MM shall inform the user application of this by 
issuing a TNMM-REPORT indication primitive where the handle parameter is set to be "de-registration". It 
is optional for the SwMI to send D-STATUS to confirm the de-registration. Hence it is optional to the MS to 
await the D-STATUS before deactivation shall be invoked, the deactivation procedure shall be as defined 
in subclause 16.3.1.2. 

NOTE: It is optional for the SwMI to send a D-STATUS PDU to confirm the 
de-registration. However, the D-STATUS should be sent before acknowledgement to 
the U-ITSI DETACH PDU. The SwMI should send D-STATUS PDU by using 
acknowledged service in the DLL. 

1 6.7 Energy economy mode procedure 



MS 



BS 



USER MM 
TNMM-ENERGY SAVING req 



TNMM-ENERGY SAVING con 



MLE-UNITDATA req . 



(U-STATUS) 



MLE-UNITDATA ind 



MLE air interface MLE 



TL-DATA req 



MM 



(D-ENERGY SAVING) 



MLE-INFO req 



TL-DATA con 



Figure 55: Change energy economy mode 



This procedure shall be initiated by the MS user application upon receipt of a TNMM-ENERGY SAVING 
request primitive and the MS MM shall issue an MLE-UNITDATA request primitive with a U-STATUS PDU 
containing the "energy saving mode" element to the infrastructure to request a specific energy economy 
group. This shall have PDU priority 1 . 

Upon receipt of a D-ENERGY SAVING PDU, the MS MM shall analyse the result of the energy economy 
group request given in the "status" element, if the D-ENERGY SAVING PDU informs the MS that the 
energy economy mode request is successful, MM shall inform the lower layers of the energy economy 
parameters in an MLE-INFO request primitive. The energy economy parameters shall be found in the 
"energy saving mode" field, which contains the energy group and energy economy start point, the latter 
comprising an absolute frame and multiframe number. MM shall inform the user application with a 
TNMM-ENERGY SAVING confirm primitive. 

If the D-ENERGY SAVING PDU informs the MS that the energy economy mode request is unsuccessful 
MM may select another energy economy mode and request that from the infrastructure using the 
procedure above. If no acceptable energy economy mode can be found, MM shall inform the user 
application with a TNMM-ENERGY SAVING confirm with "rejected" as a parameter. 

16.8 Attachment/detachment of group identities procedures 

The attachment/detachment of group identities procedures are illustrated in figures 56 and 57. 
Attachment/detachment of group identities can be initiated by the user application or it can be requested 
by the infrastructure. 

The active group identities, used as valid layer 2 group addresses, shall be defined as follows: 

1) attached by the SwMI, by using D-ATTACH/DETACH GROUP IDENTITY, D-ATTACH/DETACH 
GROUP IDENTITY ACKNOWLEDGEMENT or D-LOCATION UPDATE ACCEPT, and the MS has 
valid parameters for the group identities; 
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2) previously active group identities if in the attachment/detachment mode in D- ATTACH/DETACH 
GROUP IDENTITY, D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT or 
D-LOCATION UPDATE ACCEPT PDU were an amendment to the previously active group 
identities; 

3) not detached by the SwMI, by using D-ATTACH/DETACH GROUP IDENTITY, 
D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT or D-LOCATION UPDATE 
ACCEPT; 

4) attachment requested by the MS by using U-ATTACH/DETACH GROUP IDENTITY or 
U-LOCATION UPDATE DEMAND, and attached by the SwMI by using D-ATTACH/DETACH 
GROUP IDENTITY ACKNOWLEDGEMENT or D-LOCATION UPDATE ACCEPT; 

5) not detached by the MS by using U-ATTACH/DETACH GROUP IDENTITY or U-LOCATION 
UPDATE DEMAND; 

6) defined to be permanent and attachment is not needed. This may be defined either by using group 
identity attachment lifetime element in the attachment/detachment PDUs or by using other means 
outside of the scope of this ETS; 

7) defined to be temporary group address, active during a call (see CMCE protocol in clause 14). 

The MS shall always use a (V)GSSI instead of the GSSI when the (V)GSSI is assigned for the MS in the 
currently registered network. GSSI shall not be used as an active group identity if the currently registered 
network MCC and MNC is not the same as the MCC and MNC related to the GSSI. 



16.8.1 



Infrastructure initiated attachment/detachment of group identities procedure 



USER 



MM 



TNMM-ATTACH/DETACH 
GROUP IDENTITY ind 



MS 



MLE-UNITDATA ind 



BS 



MLE air interface 
TL-DATA req 



MLE 



MM 



(D-ATTACH/DETACH 
GROUP IDENTITY) 

MLE-UNITDATA req 



(U-ATTACH/DETACH 
GROUP IDENTITY 
ACKNOWLEDGEMENT) 



MLE-IDENTITIES req 



TL-DATA res 



Figure 56: SwMI initiated attachment/detachment of group identities 

Upon receipt the D-ATTACH/DETACH GROUP IDENTITY PDU from the MLE shall extract GSSIs and/or 
associated (V)GSSIs from group identity downlink element. The MM shall send valid group identities with 
MLE-IDENTITIES request to the MLE. If the group identity acknowledgement request field is set to 
acknowledgement requested, then the MM shall send a D-ATTACH/DETACH GROUP IDENTITY 
ACKNOWLEDGEMENT PDU to the MLE in an MLE-UNITDATA request informing the SwMI whether 
there are any group identities which are not fully defined and hence the attachment is rejected, e.g. 
unknown group identity or no valid encryption key. If the group identity report were requested, then the MM 
shall also send all active group identities within the PDU. PDU priority shall be set to 6. 

Finally the MM shall inform the user application about changes in attached/detached group identities by 
issuing a TNMM-ATTACH/DETACH GROUP IDENTITY indication The MM shall inform the user 
application using only the GTSIs while the (V)GSSIs is not known by the user application. 
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16.8.2 MS initiated attachment/detachment of group identities procedure 



MS 



BS 



USER 



MM 



TNMM-ATTACH/DETACH 
GROUP IDENTITY req 



TNMM-ATTACH/DETACH 
GROUP IDENTITY con 



MLE-UNITDATA req 



MLE air interface 



TL-DATA res 



(U-ATTACH/DETACH 
GROUP IDENTITY) 

— MLE-UNITDATA ind 



(D- ATTACH/DETACH 
GROUP IDENTITY 
ACNOWLEDGEMENT) 

MLE-IDENTITIES req ^ 



TL-DATA req 



MLE 



MM 



Figure 57: MS initiated attachment/detachment of group identities, acknowledgement requested 

Upon receipt of a TNMM-ATTACH/DETACH GROUP IDENTITY request primitive from the user 
application the MM shall send a U-ATTACH/DETACH GROUP IDENTITY PDU to the MLE in an 
MLE-UNITDATA request primitive using parameters defined in the TNMM-ATTACH/DETACH GROUP 
IDENTITY request primitive (see clause 17). PDU priority shall be set to 3. 

Upon receipt of a D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT PDU the MM shall 
extract GSSIs and/or associated (V)GSSIs from group identity downlink element and send the valid group 
identities with MLE-IDENTITIES request to the MLE. 

Finally the MM shall inform the user application by issuing a TNMM-ATTACH/DETACH GROUP 
IDENTITY confirm The MM shall inform the user application using only the GTSIs since the (V)GSSIs is 
not known by the user application. 



16.9 MM PDU structures and contents 



16.9.1 MM PDU general description 

The general format of the PDUs are defined in table 147. 

The elements shall be transmitted in the order specified by the table with the top element being 
transmitted first (before interleaving). The content of an information element is represented by a binary 
value and the most significant bit of that binary value shall be transmitted first (before interleaving). 



Table 147: PDU layout 



Information element 


Length 


Value 


Remark 


PDU type 


5 






Type 1 element (1) 


varies 




See definitions below. 


Type 1 element (2) 


varies 




See definitions below. 


...etc. 


...etc. 




...etc. 


Type 1 element (n) 


varies 




See definitions below. 


Optional bit (O-bit) 


1 


0 


No optional type 2 or type 3 elements follow 




1 


Optional type 2 or type 3 elements follow 


Presence bit (P-bit) (1) 


1 


0 


The type 2 element (1) is not present 




1 


The type 2 element (1) is present. 


Type 2 element (1) 


varies 




See definitions below. 


Presence bit (P-bit) (2) 


1 


0 


The type 2 element (2) is not present 




1 


The type 2 element (2) is present. 



(continued) 
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Table 147 (concluded): PDU layout 



Information element 


Length 


Value 


Remark 


Type 2 element (2) 


varies 




See definitions below. 


...etc. 


...etc. 




...etc. 


Presence bit (P-bit) (n) 


1 


0 


The type 2 element (n) is not present 




1 


The type 2 element (n) is present. 


Type 2 element (n) 


varies 




See type 2 element (1) 


More bit (M-bit) (1) 


1 


0 


No type 3 elements follow 




1 


Type 3 elements follow 


Type 3 element identifier (1) 


4 




See definitions below. 


Length indicator (1) 


11 


0 


Reserved. 




1-2 047 


Length of the following type 3 Element in bits: 


Type 3 element (1) 


varies 




See definitions below. 


More bit (M-bit) (2) 


1 


0 


No more type 3 elements follow 




1 


More type 3 elements follow 


Type 3 element identifier (2) 


4 




See type 3 element identifier (1) 


Length indicator (2) 


11 




See length indicator (1) 


Type 3 element (2) 


varies 




See type 3 Element (1) 


...etc. 


...etc. 




...etc. 


More bit (M-bit) (n) 


1 


0 


No more type 3 elements follow 




1 


More type 3 elements follow 


Type 3 element identifier (n) 


4 




See type 3 element identifier (1) 


Length indicator (n) 


11 




See length indicator (1) 


Type 3 element (n) 


varies 




See type 3 element (1) 


More bit (M-bit) (n+1) = 0 


1 


0 


Last M-bit (Least Significant Bit (LSB) in the PDU) = 0 



The element type defines the encoding rule applied to an element as follows: 



Type 1 elements shall be placed within the PDU in a fixed order as specified in the PDU description 
tables. The elements shall have fixed lengths as specified in the length column or variable lengths 
as indicated by a preceding length element. Each Type 1 element shall either be a mandatory 
element or conditional to a mandatory element. Type 1 elements shall be placed before any Type 2 
or Type 3 elements in the PDU. The last Type 1 element shall be followed by an O-bit. When the 
PDU contains any Type 2 or Type 3 elements the O-bit shall set to "1". When the PDU does not 
contain any Type 2 or Type 3 elements the O-bit shall be set to "0"; 

Type 2 elements are optional and shall be placed within the PDU in a fixed order as specified in the 
PDU description tables. There shall be one P-bit preceding each Type 2 element specified for the 
PDU to indicate presence of that element. The P-bit shall indicate either "Type 2 element present" 
or "Type 2 element not present". Type 2 elements shall have fixed lengths as specified in the length 
column of the PDU description tables. Type 2 elements shall be placed after all Type 1 elements 
and before any Type 3 elements in the PDU; 

Type 3 elements are optional and shall be placed within the PDU in numerical order as specified 
within the "Type 3 Element Identifier" element. Type 3 Elements shall be placed after any Type 1 
and Type 2 elements. If there are any Type 3 elements specified for the PDU an M-bit shall follow 
the Type 1 and Type 2 elements. The M-bit shall indicate either "Type 3 element to follow" or "no 
Type 3 element to follow". If there are Type 3 elements to follow, they shall be preceded by a "Type 
3 Element Identifier" element and a "Length Indicator" element in that order. A further M-bit shall 
follow the Type 3 element and after the last Type 3 element included the M-bit shall be set to "0" to 
indicate "no Type 3 element to follow". Type 3 element coding can contain sub-elements which can 
be either of Type 1 , 2 or 3. 

Element lengths, values and contents are specified in subclause 16.10 and a specific element can be 
used either as type 1 , 2 or 3 depending on the PDU. 
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The following rules shall apply for decoding of the PDU: 

DECODE Type 1 Elements; 
DECODE O-bit 

IF O-bit set to 'No Optional Elements are present' , END; 
ELSE 

DO for all possible type 2 elements, 
DECODE P-bit 

IF P-bit set to 'Present*, Decode Type 2 Element; 
END DO. 

WHILE M-bit set to 'More type 3 element follows' 

DECODE Type 3 Element 
END WHILE 

END 

The information contained in the PDU description tables which follow corresponds to the following key: 



Length: length of the element in bits; 

Type: element type (1 , 2, or 3) as defined below; 

C/O/M: conditional/optional/mandatory information in the PDU; 

Remark: comment. 

16.9.2 MM PDU description tables - downlink 

16.9.2.1 D-ATTACH/DETACH GROUP IDENTITY 

Message: D-ATTACH/DETACH GROUP IDENTITY 



Response to: 

Response expected: -/U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 
Short description: The message is sent by the infrastructure to indicate attachment/detachment of 

group identities for the MS. 



Table 148: D-ATTACH/DETACH GROUP IDENTITY contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Group identity report 


1 


1 


M 




Group identity acknowledgement request 


1 


1 


M 




Group identity attach/detach mode 


1 


1 


M 




Proprietary 




3 


O 




Group identity downlink 




3 


0 


Repeatable 



16.9.2.2 D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 



Message: D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 

Response to: U-ATTACH/DETACH GROUP IDENTITY 

Response expected: 

Short description: The message is sent by the infrastructure to acknowledge MS initiated 

attachment/detachment of group identities. 



Table 149: D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Group identity accept/reject 


1 


1 


M 




Group identity attach/detach mode 


1 


1 


M 




Proprietary 




3 


O 




Group identity downlink 




3 


0 


Repeatable 
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16.9.2.3 D-DISABLE 

Message: D-DISABLE 
Response to: 
Response expected: 

Short description: The message is sent by the Infrastructure to indicate that the MS shall be 

disabled (permanently or temporary). 

Table 150: D-DISABLE contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Disabling type 


1 


1 


M 




TETRA Equipment Identity (TEI) 


60 


1 


M 




Address extension 


24 


1 


M 




Proprietary 




3 


0 





16.9.2.4 D-ENABLE 



Message: D-ENABLE 
Response to: 
Response expected: 

Short description: The message is sent by the Infrastructure to indicate that the temporarily 

disabling shall cease. 

Table 151 : D-ENABLE contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




TETRA Equipment Identity (TEI) 


60 


1 


M 




Address extension 


24 


1 


M 




Proprietary 




3 


O 





1 6.9.2.5 D-ENERGY SAVING 



Message: D-ENERGY SAVING 

Response to: U-STATUS 
Response expected: 

Short description: This message shall be sent to the MS by the Infrastructure to indicate that the 
energy mode change is accepted or rejected. 



Table 152: D-ENERGY SAVING contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Status 


3 


1 


M 




Energy saving information 


14 


2 


O 


note 


Proprietary 




3 


O 




NOTE: If status contains -failure" meaning that no energy mode is supported the energy saving 
mode element should not be applied. 
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16.9.2.6 D-STATUS 

Message: D-STATUS 
Response to: U-ITSI DETACH 

Response expected: 

Short description: The message is sent to the MS by the infrastructure to indicate that detachment 

is confirmed 



Table 153: D-STATUS contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Status 


3 


1 


M 




Proprietary 




3 


0 





16.9.2.7 D-LOCATION UPDATE ACCEPT 



Message: D-LOCATION UPDATE ACCEPT 

Response to: U-LOCATION UPDATE DEMAND 

Response expected: 

Short description: The message is sent by the infrastructure to indicate that updating in the 

network has been completed. 



Table 154: D-LOCATION UPDATE ACCEPT contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Location update type 


3 


1 


M 




SSI 


24 


2 


O 




Address extension 


24 


2 


0 




Subscriber class 


16 


2 


0 




Energy saving information 


14 


2 


O 




SCCH information and distribution on 18th frame 


6 


2 


O 




New registered area 




3 


0 


Repeatable 


Proprietary 




3 


o 




Group identity location accept 




3 


0 
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16.9.2.8 D-LOCATION UPDATE COMMAND 

Message: D-LOCATION UPDATE COMMAND 

Response to: 

Response expected: U-LOCATION UPDATE DEMAND 

Short description: The message is sent by the infrastructure to initiate a location update demand in 

the MS. 



Table 155: D-LOCATION UPDATE COMMAND contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Group identity report 


1 


1 


M 




Cipher control 


1 


1 


M 




Ciphering parameters 


10 


1 


C 


note 


Address extension 


24 


2 


0 




Proprietary 




3 


0 




NOTE: Element "Ciphering parameters" is not present if "Cipher control" is set to "0", "ciphering 
off", either for a new registration or for a change of parameters, or, if "Cipher control" is 
set to "1", "ciphering on" and ciphering parameters are unchanged from the present state 
(for example a re-registration for some other purpose. Element "ciphering parameters" is 
present if "Cipher control" is set to "1", "ciphering on" for a new registration in that LA. 
"Cipher control" is set to "1 ", "ciphering on" and new ciphering parameters are requested. 



16.9.2.9 D-LOCATION UPDATE REJECT 



Message: D-LOCATION UPDATE REJECT 

Response to: U-LOCATION UPDATE DEMAND 

Response expected : 

Short description: The message is sent by the infrastructure to indicate that updating in the 

network is not accepted. 



Table 156: D-LOCATION UPDATE REJECT contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 




M 




Location update type 


3 




M 




Reject cause 


5 




M 




Cipher control 


1 




M 




Ciphering parameters 


10 




C 


note 


Address extension 


24 


2 


M 




Proprietary 




... 3 


O 




NOTE: Element "Ciphering parameters" is not present if "Cipher control" is set to "0", "ciphering 
off", either for a new registration or for a change of parameters, or, if "Cipher control" is 
set to "1", "ciphering on" and ciphering parameters are unchanged from the present state 
(for example a re-registration for some other purpose. Element "Ciphering parameters" is 
present if "Cipher control" is set to T, "ciphering on" for a new registration in that LA. 
"Cipher control" is set to "1", "ciphering on" and new ciphering parameters are requested. 
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16.9.2.10 D-LOCATION UPDATE PROCEEDING 

Message: D-LOCATION UPDATE PROCEEDING 

Response to: U-LOCATION UPDATE DEMAND 

Response expected: 

Short description: The message is sent to the MS by the infrastructure on registration at accepted 

migration to assign a (V) ASSI. 

Table 157: D-LOCATION UPDATE PROCEEDING contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




SSI 


24 


1 


M 




Address extension 


24 


1 


M 




Proprietary 




3 


O 





16.9.3 MM PDU descriptions - uplink 



16.9.3.1 U-ATTACH/DETACH GROUP IDENTITY 

Message: U-ATTACH/DETACH GROUP IDENTITY 

Response to: 

Response expected: D-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 
Short description: The message is sent by the MS to indicate attachment/detachment of group 

identities in the MS. 



Table 158: U-ATTACH/DETACH GROUP IDENTITY contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Group identity report 


1 


1 


M 




Group identity attach/detach mode 


1 


1 


M 




Proprietary 




3 


0 




Group identity uplink 




3 


O 


Repeatable 



16.9.3.2 U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 



Message: U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT 

Response to: D-ATTACH/DETACH GROUP IDENTITY 

Response expected: 

Short description: The message is sent by the MS to acknowledge SwMI initiated 

attachment/detachment of group identities. 



Table 159: U-ATTACH/DETACH GROUP IDENTITY ACKNOWLEDGEMENT contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Group identity acknowledgement type 


1 


1 


M 




Proprietary 




3 


O 




Group identity uplink 




3 


0 


Repeatable 
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16.9.3.3 U-ITSI DETACH 

Message: U-ITSI DETACH 

Response to: 

Response expected: D-STATUS 

Short description: The message is sent by the MS to the infrastructure to announce that the MS 
will be de-activated. 



Table 160: U-ITSI DETACH contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Address extension 


24 


2 


0 




Proprietary 




3 


0 





16.9.3.4 U-LOCATION UPDATE DEMAND 



Message: U-LOCATION UPDATE DEMAND 

Response to: 

Response expected: D-LOCATION UPDATE ACCEPT/D-LOCATION UPDATE REJECT 
Short description: The message is sent by the MS to the infrastructure to request update of its 

location registration. 



Table 161: U-LOCATION UPDATE DEMAND contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 




M 




Location update type 


3 




M 




Request to append LA 


1 




M 




Cipher control 


1 




M 




Ciphering parameters 


10 




C 


note 


Class of MS 


24 


2 


M 




Energy saving mode 


3 


2 


O 




LA information 




2 


O 




SSI 


24 


2 


o 




Address extension 


24 


2 


o 




Group identity location demand ack 




3 


o 




Group identity location demand 




3 


o 




Proprietary 




3 


0 




NOTE: Element "Ciphering parameters" is not present if "Cipher control" is set to "0", "ciphering 
off", either for a new registration or for a change of parameters, or, if "Cipher control" is 
set to "1", "ciphering on" and "Ciphering parameters" are unchanged from the present 
state (for example a re-registration for some other purpose. Element "ciphering 
parameters" is present if "Cipher control" is set to "1", "ciphering on" for a new registration 
in that LA. "Cipher Control" is set to "1", "ciphering on" and new ciphering parameters are 
requested. 
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16.9.3.5 U-STATUS 

Message: U-STATUS 
Response to: 
Response expected: 

Short description: The message is sent by the MS to the infrastructure to inform about various 

requests from the MS and executed actions like enable/disable. 



Table 162: U-STATUS contents 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


4 


1 


M 




Status 


3 


1 


M 




Energy saving mode 


3 


2 


0 


Used only when requesting 
energy economy mode 


Proprietary 




3 


0 





1 6.1 0 MM information elements coding 



1 6.1 0.1 Address extension 

The address extension element shall be used to indicate the extended part of TSI address. 



Table 163: Address extension element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Mobile Country Code (MCC) 


10 


1 


M 




Mobile Network Code (MNC) 


14 


1 


M 





16.10.2 Cipher control 



The cipher control element indicates whether ciphering is on or off. 



Table 164: Cipher control element contents 



Information element 


Length 


Value 


Remark 


Cipher Control 


1 


0 


Ciphering off 






1 


Ciphering on 



1 6.1 0.3 Cipher parameters 

The cipher parameters element includes ciphering parameters to be used according to the encoding of 
cipher control. 



Table 165: Cipher parameters element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


KSG number 


4 


1 


M 




Cipher key type 


1 


1 


M 




SCK number 


5 


1 


M 
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1 6.1 0.4 Cipher key type 

The cipher key type element indicates the key type of the air interface encryption. 



Table 166: Cipher key type element contents 



Information element 


Length 


Value 


Remark 


Cipher key type 


1 


0 


SCK 






1 


DCK 



16.10.5 Class of MS 



The purpose of the class of MS element shall be to indicate to the infrastructure the characteristics of the 
MS terminal, both hardware and software. The total element length is 24 bits and the values can be given 
both as a bit map and as values. The decoding shall be as follows: 



Table 167: Class of MS element contents 



Information sub-element 


Length 


Value 


Remark 


Frequency simplex/duplex 


1 


0 


Frequency simplex 






1 


Frequency duplex 


Single/multislot 




0 


Single slot 






1 


Multislot 


Concurrent multicarrier operation 


1 


0 


Single carrier operation 






1 


Multi carrier operation 


Voice 




0 


No voice 






1 


Voice 


End-to-end encryption 


1 


0 


Encrypted 






1 


Not encrypted 


circuit mode data 




u 


No circuit mode data 






1 


Circuit mode data 


SCLNP 




0 


No SCLNP 






1 


SCLNP 


CONP 




0 


No CONP 






1 


CONP 


Air interface encryption 




0 


No air interface encryption 






1 


Air interface encryption 


CLCH needed on carrier change 




0 


No CLCH needed on carrier change 






1 


CLCH needed on carrier change 


Concurrent channels 




0 


No concurrent channels 


(i.e. concurrent services) 




1 


Concurrent channels 


Advanced link 




0 


No advanced link 






1 


Advanced link 


Minimum mode 




0 


No minimum mode 






1 


Minimum mode 


Carrier specific signalling channel 




0 


No carrier specific signalling channel 






1 


Carrier specific signalling channel 


Reserved 


2 




Bit-map reserved for future expansion 


TETRA air interface standard 


3 


000? 


ETS 300 392 Edition 1 


version number 




001? 


Reserved 






...etc. 


...etc. 






111? 


Reserved 


Reserved 


5 




Reserved for future expansion 
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16.10.6 Class of usage 

The purpose of the class of usage element to define relative priority of the group identity. The class of 
usage has meaning only for the user application. 



Table 168: Class of Usage element contents 



Information element 


Length 


Value 


Remark 


Class of usage 


3 


000? 


Class of usage 1 






001? 


Class of usage 2 






01 0 2 


Class of usage 3 






011? 


Class of usage 4 






100? 


Class of usage 5 






101? 


Class of usage 6 






110? 


Class of usage 7 






111? 


Class of usage 8 



16.10.7 Disabling type 

The purpose of the disabling type element shall be to indicate which of the disabling types (i.e. temporary 
or permanent) is requested. 



Table 169: Disabling type element contents 



Information element 


Length 


Value 


Remark 


Disabling type 


1 


0 


Temporary 






1 


Permanent 



1 6.1 0.8 Distribution on 1 8th frame 



The purpose of the distribution on 18th frame element shall be to indicate on which of the 4 time slots the 
MS shall monitor down link information in the case of minimum mode. 



Table 170: Distribution on 18th frame element contents 



Information element 


Length 


Value 


Remark 


Distribution on 18th frame 


2 


00? 


Time slot 1 






01? 


Time slot 2 






10? 


Time slot 3 






11? 


Time slot 4 



1 6.1 0.9 Energy saving mode 

The energy saving mode element shall be used to indicate which energy saving scheme is requested (if 
any). 



Table 171: Energy saving mode element contents 



Information element 


Length 


Value 


Remark 


Energy saving mode 


3 


000? 


Stay Alive 






001? 


Economy mode 1 (EG1) 






010? 


Economy mode 2 (EG2) 






011? 


Economy mode 3 (EG3) 






100 2 


Economy mode 4 (EG4) 






101? 


Economy mode 5 (EG5) 






110? 


Economy mode 6 (EG6) 






111? 


Economy mode 7 (EG7) 
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1 6.1 0.1 0 Energy saving information 

The energy saving information element shall be used to indicate which energy saving scheme is 
requested (if any) and starting point of the energy economy mode. 



Table 172: Energy saving information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Energy saving mode 


3 


1 


M 




Frame Number 


5 


1 


M 




Multiframe Number 


6 


1 


M 





16.10.11 Frame Number (FN) 



The FN element shall be used to indicate TDMA frame number. 



Table 173: FN element contents 



Information element 


Length 


Value 


Remark 


Frame Number (FN) 


5 


00000 2 


Reserved 






00001 2 


FN1 






0001 0 2 


FN2 






...etc. 


...etc. 






10010? 


FN18 






10011? 


Reserved 






...etc. 


...etc. 






11111? 


Reserved 



1 6.1 0.1 2 Group identity accept/reject 



The group identity accept/reject element is used to indicate the infrastructure response type to the MS 
initiated attachment/detachment of group identities. 



Table 174: Group identity accept/reject element contents 



Information element 


Length 


Value 


Remark 


Group identity accept/reject 


1 


0 


Attachment/detachment accepted 






1 


Attachment(s) rejected, the reject cause is 
indicated in the group identity downlink 
element 



1 6.10.1 3 Group identity acknowledgement request 

The group identity acknowledgement request element is used to indicate the MS response to the 
infrastructure initiated attachment/detachment of group identities. 



Table 175: Group identity acknowledgement request element contents 



Information element 


Length 


Value 


Remark 


Group identity acknowledgement request 


1 


0 


Acknowledgement not requested 






1 


Acknowledgement requested 
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1 6.1 0.1 4 Group identity acknowledgement type 

The group identity acknowledgement type element is used to indicate the MS response type to the 
infrastructure initiated attachment/detachment of group identities. 



Table 176: Group identity acknowledgement type element contents 



Information element 


Length 


Value 


Remark 


Group identity acknowledgement type 


1 


0 


Attachment/detachment accepted 






1 


Attachment(s) rejected, the reject 
cause is indicated in the group identity 
uplink element 



1 6.1 0.1 5 Group identity address type 

The group identity address type element is used to indicate type of group identity address type in the 
attachment/detachment of group identities. 



Table 177: Group identity address type element contents 



Information element 


Length 


Value 


Remark 


Group identity address type 


2 


00p 


GSSl 






01 ? 


GTSI 






10 ? 


(V)GSSI 






11 2 


GTSI+(V)GSSI 



16.10.16 Group identity attachment lifetime 

The group identity attachment lifetime element is used to indicate a lifetime of the attachment of the group 
identity defined by the infrastructure for a MS. 



Table 178: Group identity attachment lifetime element contents 



Information element 


Length 


Value 


Remark 


Group identity attachment lifetime 


2 


00? 


Permanent, attachment not needed 






01 2 


Permanent, attachment for next session 
required 






10 P 


Session based, attachment not allowed 






11p 


Reserved 



1 6.1 0.1 7 Group identity attach/detach mode 

The group identity attach/detach mode element is used to indicate a mode of the attachment/detachment 
of group identities. 



Table 179: Group identity attach/detach mode element contents 



Information element 


Length 


Value 


Remark 


Group identity attach/detach mode 


1 


0 


Amendment 






1 


Detach all currently active group identities 
and attach group identities defined in the 
group identity (downlink/uplink) element (if 
any) 



Page 234 

ETS 300 392-2: March 1996 

1 6.1 0.1 8 Group identity attach/detach type identifier 

The group identity attach/detach type Identifier element is used to indicate the whether a group identity is 
attached or detached. 



Table 180: Group identity attach/detach type Identifier element contents 



Information element 


Length 


Value 


Remark 


Group identity attach/detach type identifier 


1 


0 


Attachment 






1 


Detachment 



16.10.19 Group identity attachment 

The group identity attachment element shall be used to join the infrastructure attachment parameters. 
Table 181 : Group identity attachment element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity attachment lifetime 


2 


1 


M 




Class of Usage 


3 


1 


M 





1 6.1 0.20 Group identity detachment downlink 

The group identity detachment downlink element is used to indicate the infrastructure detachment 
reasons. 



Table 182: Group identity detachment downlink element contents 



Information element 


Length 


Value 


Remark 


Group identity detachment downlink 


2 


00? 


Unknown group identity 






01? 


Temporary detachment 






102 


Session based detachment 






11? 


Permanent detachment 



1 6.1 0.21 Group identity detachment uplink 

The group identity detachment uplink element is used to indicate the MS detachment reasons. 

Table 183: Group identity detachment uplink element contents 



Information element 


Length 


Value 


Remark 


Group identity detachment uplink 


2 


00? 


Unknown aroup identity 






01? 


No valid encryption key (end-to-end) 






10? 


User initiated 






11 2 


Reserved 
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1 6.1 0.22 Group identity downlink 

The group identity downlink element shall be used to join the parameters for a group identity 
attachment/detachment used by the infrastructure. 



Table 184: Group identity downlink element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity attach/detach type identifier 


1 




M 




Group identity attachment 


5 




C 


note 1 


Group identity detachment downlink 


2 




C 


note 1 


Group identity address type 


2 




M 




GSSI 


24 




C 


note 2 


Address EXTENSION 


24 




C 


note 2 


(V) GSSI 


24 




c 


note 2 


NOTE 1: 
NOTE 2: 


Shall be conditional on the value of Group Identity Attach/Detach Type Identifier (GIADTI): 

GIADTI = 0; Group Identity Attachment; 

GIADTI = 1 ; Group Identity Detachment Downlink. 
Shall be conditional on the value of Group Identity Address Type (GIAT): 

GIAT = 0; GSSI; 

GIAT = 1 ; GSSI + Address Extension (GTSI); 

GIAT = 2; Visitor Group Short Subscriber Identity ((V)GSSI); 

GIAT = 3; GSSI + Extension + Visitor Group Short Subscriber Identity 

(GTSI-V(GSSI)). 



1 6.1 0.23 Group identity location accept 



The group identity location accept element shall be used to join attachment/detachment of group identities 
information in the D-LOCATION UPDATE ACCEPT PDU. 



Table 185: Group identity location accept element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity accept/reject 


1 


1 


M 


note 


Group identity attach/detach mode 


1 


1 


M 




Group identity downlink 




3 


O 


Repeatable 


NOTE: Accept/reject used only when acknowledging MS group identity attachment/detachment. 



1 6.1 0.24 Group identity location demand 



The group identity location demand element shall be used to join attachment/detachment of group 
identities information in the U-LOCATION UPDATE DEMAND PDU. 



Table 186: Group identity location demand element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity report 


1 


1 


M 




Group identity attach/detach mode 


1 


1 


M 




Group identity uplink 




3 


O 


Repeatable 



16.10.25 Group identity location demand ack 

The group identity location demand ack element shall be used to join attachment/detachment of group 
identities information in the U-LOCATION UPDATE DEMAND PDU. 



Table 187: Group Identity Location Demand Ack element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity acknowledgement type 


1 


1 


M 




Group identity uplink 




3 


O 


Repeatable 
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1 6.1 0.26 Group identity report 

The group identity report element is used to interrogate that all MS's active group identities must be 
reported. 



Table 188: Group identity report element contents 



Information element 


Length 


Value 


Remark 


Group identity report 


1 


0 


Not report request 






1 


Report request 



16.10.27 Group identity uplink 

The group identity uplink element shall be used to join the parameters for a group identity 
attachment/detachment used by the MS. 



Table 189: Group identity uplink element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Group identity attach/detach type identifier 


1 


1 


M 




Class of usaqe 


3 


1 


C 


note 1 


Group identity detachment uplink 


2 


1 


C 


note 1 


Group identity address type 


2 


1 


M 




GSSI 


24 


1 


C 


note 2 


Address extension 


24 


1 


C 


note 2 


(V) GSSI 


24 


1 


C 


note 2 


NOTE 1 : 
NOTE 2: 


Shall be conditional on the value of Group Identity Attach/Detach Type Identifier (GIADTI): 

GIADTI = 0; Class of Usage; 

GIADTI = 1 ; Group Identity Detachment uplink. 
Shall be conditional on the value of Group Identity Address Type (GIAT): 

GIAT = 0; GSSI; 

GIAT = 1; GSSI + Address Extension (GTSI); 

GIAT = 2; Visitor Group Short Subscriber Identity ((V)GSSI); 

GIAT = 3; Reserved. 



16.10.28 Group Short Subscriber Identity (GSSI) 



The GSSI element is used to indicate the GSSI or (V)GSSI that the MS shall use in subsequent contacts 
with the SwMI. It is also used during attachment/detachment to explicitly inform the full GTSI when used in 
conjunction with the extension element. 



Table 190: GSSI element contents 



Information element 


Length 


Value 


Remark 


GSSI 


24 




See ETS 300 392-1 [1 11 clause 7 



16.10.29 KSG number 



The KSG number element shall indicate the selection between key stream generators 



Table 191: KSG number element contents 



Information element 


Length 


Value 


Remark 


KSG number 


4 


0000? 


TETRA KSG 






...etc. 


etc 






0111? 


TETRA KSG 






1000? 


Proprietary KSG 






...etc. 


...etc. 






1111? 


Proprietary KSG 
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16.10.30 LA 

The LA element shall be used to indicate the area in which a cell is located, either the serving cell or a 
neighbour cell. 



Table 192: LA element contents 



Information element 


Length 


Value 


Remark 


LA 


14 







16.10.31 LACC 



The LACC element shall be used to indicate which LACC the MS wants to use. The element shall only be 
signalled if it is different from the country code used in the network, i.e. the MS is migrating. 



Table 193: Location Area Country Code element contents 



Information element 


Length 


Value 


Remark 


Location Area Country Code 


10 




See ETS 300 392-1 f1 1], clause 7 (MCC) 



16.10.32 LANC 



The LANC element is used to indicate which LANC the MS wants to use. The element is only signalled if it 
is different from the network code used in the network, i.e. the MS is roaming. 



Table 194: LANC element contents 



Information element 


Length 


Value 


Remark 


Location Area Network Code 


14 




See ETS 300 392-1 [1 11 clause 7 (MNC) 



16.10.33 LA timer 



The LA timer element is used to indicate the time a LA is valid. 



Table 195: LA timer element contents 



Information element 


Length 


Value 


Remark 


LA timer 


3 


000? 


5 min 






001? 


10 min 






010? 


15 min 






011? 


20 min 






100? 


30 min 






101? 


45 min 






110? 


60 min 






111? 


no timing 



16.10.34 LA information 



The LA information element includes the LA, LACC and LANC information. 



Table 196: LA information element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


Location Area (LA) 


14 


1 


M 




Location Area Country Code (LACC) 


10 


2 


O 




Location Area Network Code (LANC) 


14 


2 


O 
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1 6.1 0.35 Location update type 

The purpose of the location updating type element shall be to indicate what type of registration is wanted. 



Table 197: Location update type element contents 



Information element 


Length 


Value 


Remark 


Location update type 


3 


000p 


Roaminq location updating 






001? 


Migrating location updating 






01 Op 


Periodic location updating 






011? 


ITSI attach 






100? 


Call restoration roaming location updating 






101? 


Call restoration migrating location updating 






110 2 


Demand location updating 

(D-Location Update command received) 






111? 


Disabled MS updating 



16.10.36 MCC 



The MCC element shall indicate to which MCC the MS is subscribed. The element shall only be signalled 
if it is different from the country code used in the network. 



Table 198: MCC element contents 



Information element 


Length 


Value 


Remark 


MCC 


10 




See ETS 300 392-1 [1 11, clause 7 (MCC) 



16.10.37 MNC 



The MNC element shall indicate to which MNC the MS is subscribed. The element shall only be signalled 
if it is different from the network code used in the network. 



Table 199: MNC element contents 



Information element 


Length 


Value 


Remark 


MNC 


14 




See ETS 300 392-1(1 1], clause 7 (MNC) 



16.10.38 Multiframe Number (MN) 



The MN element shall be used to indicate TDMA multiframe number 



Table 200: MN element contents 



Information element 


Length 


Value 


Remark 


Multiframe Number (MN) 


6 


000000? 


Reserved 






000001? 


MN1 






000010? 


MN2 






...etc. 


...etc. 






111100? 


MN60 






111101? 


Reserved 






...etc. 


...etc. 






111111? 


Reserved 
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16.10.39 PDUtype 

The PDU type element shall be used to identify a up-link and down-link message. The PDU type element 
shall have a separate definitions in the uplink and downlink directions as shown below. 



Table 201: PDU type element contents 



Information 


Length 


Value 


Remark 


element 






rinufnlinlf 

UUWI llll 11V 


Unlink 


PDU tvDe 


4 


OOOO2 


ncoclvcU 


ncocIVcU IUI 








I l-AI JTHFNITinATinNI 

\J r\\J 1 1 1 LIN 1 IvA 1 IvIM 










RESPONSE 






0001 2 


ncocIVcU IUI 


1 1-ITQI nFTAPH 
VJ 1 1 Ol Ly L 1 nOn 
















001 0 2 




1 1-1 OPATinNJ I JPHATF 






n.Al ITHFMT1PATIHM RF IFHT 
u nU I iiLm 1 ivn 1 ivjiN n lulu i 








0011? 


n.niQARi f 








01002 


U-CInADLC 


neserveo ior 








1 J-AI ITHFMTinATIONI HKAD 






01 01 2 


n.l OPATinM 1 IPnATF APPFPT 


Qocon/oH 






0110 2 


n.l nPATIHN 1 IPRATF 
U'LUvn 1 1 WIN UrL/n 1 C 


Qocon/oH ir\f 
ncocivcu \\Jl 






COMMAND 


U-AUTHENTICATION RESULT 






0111 2 


D-LOCATION UPDATE RESULT 


U-ATTACH/DETACH GROUP 










IDENTITY 






1000 2 


Reserved for 


U-ATTACH/DETACH GROUP 






D-AUTHENTICATION RESP 


IDENTITY ACK 






1001 2 


D-LOCATION UPDATE 


Reserved 








PROCEEDING 








1010 2 


D-ATTACH/DETACH GROUP 


Reserved 






IDENTITY 








1011 2 


D-ATTACH/DETACH GROUP 


Reserved 








IDENTITY ACK 








1100? 


D-ENERGY SAVING 


Reserved 






1101? 


D-STATUS 


Reserved 






1110? 


Reserved 


Reserved 






11112 


Reserved 


Reserved 



1 6.1 0.40 New registered area 

The new registered area element shall be used to download the LAs contained in the new registered area. 



Table 202: New registered area element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


LA timer 


3 


1 


M 




LA 


14 


1 


M 




LACC 


10 


2 


O 




LANC 


14 


2 


0 





16.10.41 Proprietary 

Proprietary is an optional, variable length element and shall be used to send and receive proprietary 
defined information appended to the PDUs. 

The use, the size and the structure of the proprietary element is outside the scope of this standard. 
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1 6.1 0.42 Reject cause 

The purpose of the reject cause element is to indicate what type of rejection has been detected. 



Table 203: Reject cause element contents 



Information element 


Length 


Value 


Remark 


Reject cause 


5 


00000? 


Reserved 






00001 p 


ITSI unknown 






00010? 


Illegal MS 






00011? 


LA not allowed 






001 00 2 


LA unknown 






00101? 


Network failure 






00110? 


Congestion 






00111? 


Service not supported 






01000? 


Service not subscribed 






01001? 


Mandatory element error 






01010? 


Message consistency error 






01011? 


Roaming not supported 






01100? 


Migration not supported 






01101? 


No cipher KSG 






01110? 


Identified cipher KSG not supported 






01111? 


Requested cipher key type not available 






10000? 


Identified cipher key not available 






10001? 


Incompatible service 






10010? 


Reserved 






...etc. 


...etc. 






11111? 


Reserved 



1 6.1 0.43 Request to append LA 

The purpose of the request to append LA element shall be to indicate whether the MS user wants to 
append the new LA into the current registered area or not. 



Table 204: Request to Append LA element contents 



Information element 


Length 


Value 


Remark 


Request to append LA 


1 


0 


No request to append LA to registered 
area 






1 


Request to append LA to registered area 



16.10.44 SSI 



The element is used to indicate the ASSI or (V)ASSI that the MS shall use in subsequent contacts with the 
SwMI. It can also be used during registration to explicitly inform the SwMI of the full ITSI when used in 
conjunction with the MCC and MNC. 



Table 205: SSI element content 



Information element 


Length 


Value 


Remark 


Short Subscriber Identity (SSI) 


24 




See ETS 300 392-1 [111, clause 7 
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16.10.45 SCCH information 

The SCCH information element shall be to assign parameters used by the MAC to calculate which CCCH 
to use when common SCCHs are in operation. 



Table 206: SCCH information element contents 



Information element 


Length 


Value 


Remark 


SCCH information 


4 


0000? 


MS SCCH allocation 0 






0001? 


MS SCCH allocation 1 






...etc. 


...etc. 






1011? 


MS SCCH allocation 11 






1100? 


Reserved 






...etc. 


...etc. 






1111? 


Reserved 



16.10.46 SCCH information and distribution on 18th frame 



The purpose of the SCCH information and distribution on 18th frame element shall be to inform the MS of 
any SCCH information and on which of the 4 time slots the MS shall monitor down link information in the 
case of minimum mode. 



Table 207: SCCH information and distribution on 18th frame element contents 



Information sub-element 


Length 


Type 


C/O/M 


Remark 


SCCH information 


4 


1 


M 




Distribution on 18th frame 


2 


1 


M 





16.10.47 SCK number 



The SCK number element shall indicate the value of static cipher key. A choice of 32 possible values of 
SCK is offered. This field shall be set to all zeroes if DCK is specified. 



Table 208: SCK number element contents 



Information element 


Length 


Value 


Remark 


SCK Number 


5 


00000? 


SCK 1 






00001? 


SCK 2 






...etc. 


...etc. 






11111? 


SCK 32 



16.10.48 Status 



The purpose of the status element shall be to give information on execution status of an action. 



Table 209: Status element content 



Information element 


Length 


Value 


Remark 


Status 


3 


000? 


Reserved 






001? 


Change of energy saving mode request (MS) 






010? 


Change of energy saving mode successful (SwMI) 






011? 


ITSI detach confirmation (SwMI) 






100? 


Failure 






101? 


Reserved 






110? 


Reserved 






111? 


Reserved 
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16.10.49 Subscriber class 

The subscriber class element shall be used to subdivide the MS population in up to 16 classes (see 
definition) represented as a bit map. 



Table 210: Subscriber Class element 



Information element 


Length 


Value 


Remark 


Class 1 


1 


0 


Not a member 






1 


Member 


Class 2 


1 


0 


Not a member 






1 


Member 


...etc. 


1 


0 


...etc. 






1 


...etc. 


Class 16 


1 


0 


Not a member 






1 


Member 



16.10.50 TEI 



The TEI element shall be used to indicate the TETRA Equipment Identity (TEI). 



Table 211: TEI element content 



Information element 


Length 


Value 


Remark 


TETRA Equipment Identity 


60 




See ETS 300 392-1 [111, clause 7 



16.10.51 Type 3 element identifier 

The purpose of the Type 3 element identifier element is to indicate the type of the following Type 3 
element in the PDU. 



Table 212: Type 3 element identifier element contents 



Information element 


Length 


Value 


Remark 


Type 3 element identifier 


4 


0000? 


Reserved 






0001? 


Group identity location demand ack 






0010? 


New reqistered area 






0011? 


Group identity location demand 






0100? 


Proprietary 






0101? 


Group identity location accept 






0110? 


Security 






0111? 


Group identity downlink 






1000? 


Group identity uplink 






1001? 


Reserved for any future specified Type 3 element 






...etc. 


...etc. 






1111? 


Reserved for any future specified Type 3 element 



16.10.52 (V)GSSI 

The purpose of the (V)GSSI element shall be to indicate the (V)GSSI that the MS shall use in subsequent 
contacts with the SwMI. 



Table 213: (V)GSS1 element contents 



Information element 


Length 


Value 


Remark 


Visitor Group Short Subscriber Identity 


24 




See ETS 300 392-1 f1 11, clause 7 
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16.11 Parameters 
16.11.1 Timers 

16.11.1.1 Timer T351: Registration response time 

This shall be the maximum time MM is waiting for a response for a registration request. The timer T351 
value shall be 30 seconds. 

17 MLE service description 

17.1 Introduction 

This clause describes the services offered by the MLE. 

The assumed underlying protocol is a MLE protocol, which is assumed to be positioned in the lowest sub- 
layer of layer 3 of the air interface stack. 

The MLE services are provided through a set of SAPs t with each SAP corresponding to one type of 
service user (one upper layer 3 protocol). 

The MLE protocol has been designed to hide most of the radio aspects of the air interface, and the 
resulting MLE services are intended to be comparable to non-radio (line) layer 2 protocols. 

NOTE: Identical service definitions should also be used for LSs to allow the use of identical 
upper layer 3 protocols in LSs. 

The MLE service boundary is an internal sub-layer boundary that is defined to clarify the description of the 
air interface layer 3. It is not intended to be a testable boundary. Conformance to this service should be 
achieved by providing conformance to one of the assumed MLE protocols. 

17.2 Summary of services offered by MLE protocol 

The MLE provides services to MLE service users. These services should be made available through 
SAPs. This relationship is shown as follows: 



Service User 





SAP 









Service Provider 

Figure 58: Relationship between a service user and a service provider 

The entities listed below shall be permitted to use MLE services: 

Mobility Management (MM) entity (see clause 1 6); 

Circuit Mode Control Entity (CMCE) (see clause 14); 

Connection Oriented Network Protocol (CONP) entity (see clause 25); 

Specific Connectionless Network Protocol (SCLNP) entity (see clause 27). 

All of the permitted MLE service users need not be present. However, in order that the MLE services may 
be requested, at least some of the permitted MLE service users should be present. For example, a V+D 
MS may choose not to implement the CONP entity. The MLE shall not be required to support the MLE 
service users which are not present. 



Page 244 

ETS 300 392-2: March 1996 



The MLE services are represented by the set of MLE service primitives which are available via the various 
SAPs listed below: 



Table 214: SAPs 



SAP name 


Upper layer 3 protocol (service user) 


Reference 


LMM-SAP 


Mobility Management (MM) 


subclause 17.3.1. 


LCMC-SAP 


Circuit Mode Control Entity (CMCE) 


subclause 17.3.2. 


LCO-SAP 


Connection Oriented Network Protocol (CONP) 


subclause 17.3.4. 


LSCL-SAP 


Specific Connectionless Network Protocol (SCLNP) 


subclause 17.3.3. 



With the exception of the LMM-SAP, the services offered at each SAP should be independent of each 
other, and the service at each of the other SAPs should operate using an independent set of primitives. 
The LMM-SAP can act as a "master SAP", enabling and disabling service provision at the other SAPs. 



The LCO-SAP and LSCL-SAP may support multiple independent instances of higher protocol (multiple 
instances of CONP and SCLNP, each with an independent set of primitives) but each instance must be 
associated with a different TSI family. All TSI families associated with CONP and SCLNP within 1 MS/LS 
shall be associated with a single instance of MM protocol. 

NOTE: Multiple TSI families are the normal situation on the TETRA infrastructure side. Most 
MSs contain only one TSI family, but multiple TSI families may co-exist in one MS (see 
ETS 300 392-1 [11], clause 7). 

Figure 59 and figure 60 show the service relationships relating to the MLE services. 



MM 




CMCE 




CONP 




S-CLNP 



S-CLNP 




CONP 




CMCE 




MM 



~ (£mm)~ 




MLE (and lower layers) 



data 
transfer 
relation- 
ships 



MLE (and lower layers) 



Mobile Side Air Interface Infrastructure Side 

Figure 59: Services relationships offered by the MLE in the air interface 
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MS 


BS 


ISSI 




ISSI 





ISSI used for point-to-point links for CMCE, CONP or S-CLIMP 



MS#1 



GSSI 



MS#2 



GSSI 



MS#3 



GSSI 



BS 



GSSI 



GSSI used for point-to-multipoint links for CMCE or S-CLNP 

Figure 60: Address relationships with respect to NILE services 
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17.3 Service descriptions 

The following service descriptions describe the MLE services provided to the higher layers in the MS 
protocol stack. 

17.3.1 Service state diagram for the LMM-SAP 

The primitives provided by the MLE to the MM entity should be as shown in table 215. 



Table 215: Primitives and parameters at the LMM-SAP 



Primitives generic name 


Specific name 


Parameters 


MLE-ACTIVATF 

i v 1 1_ i i i v n i i— 


rpnuest 


MCC 
MNC 




confirm 


Registration required 
LA 




IMUICclUUH 




MLt-DUo Y 


rnni i Act 




MLE-CANCEL 


request 


Handle 


MLE-CLOSE 


request 




MLE-DEACTIVATE 


request 




MLE-IDENTITIES 


request 


ISSI 
ASSI 

Atiacneo uoois 
Detached GSSIs 


MLE-IDLE 


request 




MLE-INFO 


request 


Subscriber class 

SCCH configuration 

Energy economy mode configuration 

Minimum Mode configuration 


MLE-LINK 


indication 


MCC 
MNC 

1 A 

LA 

Registration type 


MLE-OPEN 


request 




MLb-rHtrAHL 


request 


ouu 

Layer 2 service 
PDU priority 
Stealing permission 
Stealing repeats flag 




confirm 


SDU 


MLE-REPORT 


indication 


Handle 

Transfer result 


MLE-UNITDATA 


request 


SDU 

Layer 2 service 
PDU priority 
Stealing permission 
Stealing repeats flag 
Encryption flag 




indication 


SDU 


MLE-UPDATE 


request 


MCC 
MNC 

Registration Result 
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The transactions between the states should be as shown in figure 61 . 

MLE-DEACTIVATE 

Null 



request 



MLE-DEACTIVATE requesl 





3 



MLE-UPDATE request 
MLE-LINK indication 
MLE-ACTIVATE indication 
MLE-CANCEL request 



MLE-OPEM 
request 



MLE-UNITDATA request 
MLE-UNITDATA indication 
MLE-REPORT indication 
MLE-IDENTITIES request 
MLE-INFO request 



MLE-UNITDATA request 
MLE-UNITDATA indication 
MLE-REPORT indication 
MLE-OPEN request 
MLE-BUSY request 
MLE-IDLE request 
MLE-PREPARE request 
MLE-PREPARE confirm 
MLE-IDENTITIES request 
MLE-INFO request 



Figure 61: LMM-SAP state transition diagram 



17.3.2 



Service primitives for the LMM-SAP 



MLE-ACTIVATE request: this shall be used as a request to initiate the selection of a cell for 
communications. The request shall always be made after power on and may be made at any time 
thereafter. 

MLE-ACTIVATE confirm: this shall be used as a confirmation to the MM entity that a cell has been 
selected with the required characteristics. 

MLE-ACTIVATE indication: this shall be used as an invitation to the MM to react as no suitable cell is 
available. 



MLE-BUSY request: this shall be used by the MM entity to prevent the MLE from accepting a group- 
addressed channel change during an MM protocol exchange. 

MLE-CANCEL request: this may be used by the MM to delete a previous request issued but not yet 
transmitted. The ability to cancel shall be removed when the MLE-REPORT indication is received, 
indicating transmission of the MM PDU. 

MLE-CLOSE request: this shall be used by the MM entity to instruct the MLE to remove access to 
communication resources for the other layer 3 entities, but keeping access to the communication 
resources for the MM entity. 

MLE-DEACTIVATE request: this shall be used by the MM entity to request the de-activation of all MLE 
procedures and to return to the NULL state. No communication resources are available for use after this 
primitive has been issued. 



Page 248 

ETS 300 392-2: March 1996 



MLE-IDENTITIES request: this primitive shall be used to transfer the identities that have been received 
from the SwMI to the MLE t and layer 2. 

MLE-IDLE request: this shall be used by the MM entity to release the MLE from rejecting any group 
addressed channel change commands from the SwMI. 

MLE-INFO request: this primitive shall be used to transfer control parameters received from the SwMI to 
the MLE and layer 2. These control parameters include information on energy economy modes, control 
channel configurations and subscriber class. 

MLE-LINK indication: this shall be used by the MLE to indicate to the MM entity that the MS has selected 
or is about to select a cell outside the Registered Area (RA). 

MLE-OPEN request: this shall be used by the MM entity to instruct the MLE to provide access to 
communication resources for other layer 3 entities after successful registration. 

MLE-PREPARE request: this shall be used by the MM entity to instruct the MLE to forward register 
during announced type 1 cell re-selection. 

MLE-PREPARE confirm: this shall be used by the MLE to confirm forward registration during announced 
type 1 cell re-selection. 

MLE-REPORT indication: this shall be used by the MLE to report on the completion of an MLE- 
UNITDATA request procedure. The result of the transfer attempt is passed as a parameter. Errors 
detected during the MLE-UNITDATA request procedure are indicated using this primitive. 

MLE-UNITDATA request: this shall be used by the MM entity to request a data transmission A parameter 
indicates which layer 2 service is required. 

MLE-UNITDATA indication: this shall be used by the MLE to pass to the MM entity data which has been 
received from the SwMI. 

MLE-UPDATE request: this shall be used by the MM entity to inform the MLE about new criteria 
concerned with the monitoring of other possible cells. 
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1 7.3.3 Service state diagram for the LCMC-SAP 

The primitives provided by the MLE to the CMCE are as shown in table 216. 



Table 216: Primitives and parameters at the LCMC SAP 



Generic name 


Specific name 


Parameters 


hill EZ QDCAI/ 

MLb-bnbAK 


indication 




hill C /^AMPCI 

MLb-OAlNUbL 


request 




hiii c r*\ ncc 
MLb-ULUob 


maication 




Kill C PAMCIOI IDC 

M Lb-UU IM r I ta U H b 


request 


cnupoini lueniiTier 
Channel change accept 

^all ro Iosco 
wall iclcaoc 

Encryption flag 
Circuit mode type 
Simplex/duplex 
Add temporary GSSI 

nplptp tpmnnrarv f^SSI 
Tx a rant 
Switch U Plane 


MLE-IDENTITIES 


request 


List of GSSIs 


MLE-OPEN 


indication 




MLE-REOPEN 


indication 




MLE-REPORT 


indication 


Handle 

Transfer result 


MLE-RESTORE 


request 


cm i 

Layer 2 sen/ice 
PDU priority 
Stealing permission 
Stealing repeats flaq 




UUMIU IM 




MLE-RESUME 


indication 




MLE-UNITDATA 


request 


SDU 

Endpoint identifier 
Layer 2 service 
PDU priority 
Stealing permission 
Stealing repeats flag 




indication 


SDU 

Endpoint identifier 
Received TETRA address 
Received address type 
Channel change response required 
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The state transitions visible at this SAP shall be as shown in figure 62. 




i-RESUME indication 
i-REOPEN indication 



Figure 62: State transition diagram of LCMC-SAP 
1 7.3.4 Service primitives for LCMC-SAP 

MLE-BREAK indication: this primitive shall be used by the MLE to inform the CMCE that access to the 
communication resources is temporarily unavailable and that the data transfer service cannot be used. 

MLE-CANCEL request: this primitive shall be used by the CMCE to delete a previous request issued but 
not yet successfully transmitted. The ability to cancel shall be removed when the MLE-REPORT indication 
is received, indicating successful transmission of the CMCE PDU. 

MLE-CLOSE indication: this primitive shall be used by the MLE to indicate to the CMCE that access to 
the communications resources has been removed and that data transfer service cannot be used. 

MLE-CONFIGURE request: this primitive shall be used to pass inter layer management information 
relating to circuit mode calls, e.g. whether Tx grant has been given, type of traffic etc. 

MLE-IDENTITIES request: this primitive shall be used by the CMCE to inform the MLE and layer 2 of a 
change to the list of group identities. 

MLE-OPEN indication: this primitive shall be used by the MLE to inform the CMCE that it has access to 
the communication resources and that the data transfer service can be used. 

MLE-REOPEN indication: this primitive shall be used by the MLE to inform the CMCE that access to the 
communication resources is once again available. The data transfer service can now be used but the 
CMCE cannot attempt to restore any circuit mode calls. 

MLE-REPORT indication: this shall be used by the MLE to report on the completion of an MLE- 
UNITDATA request procedure. The result of the transfer attempt shall be passed as a parameter. Errors 
detected during the MLE-UNITDATA request procedure shall be indicated using this primitive. 

MLE-RESTORE request: this primitive shall be used by the CMCE to restore a call after a successful cell 
re-selection. 
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MLE-RESTORE confirm: this primitive indicates the success or failure of call restoration to the CMCE as 
a result of a previously issued MLE-RESTORE request. 

NILE-RESUME indication: this primitive shall be used by the MLE to inform the CMCE that access to the 
communication resources is once again available. The data transfer service can now be used and the 
CMCE may attempt to restore any circuit mode calls. 

MLE-UNITDATA request: this primitive shall be used by the CMCE to send unconfirmed data to a peer 
entity on the TETRA infrastructure side. Parameter indicates which layer 2 service is required. 

MLE-UNITDATA indication: this primitive shall be used by the MLE to pass to the CMCE entity data 
which has been received from a peer entity on the TETRA infrastructure side. 

1 7.3.5 Service state diagram for the LSCL-SAP 

The primitives provided by the MLE to the SCLNP entities should be as shown in table 217. 



Table 217: Primitives and parameters at the LSCL SAP 



Generic name 


Specific name 


Parameters 


MLE-CLOSE 


indication 




MLE-OPEN 


indication 




MLE-REPORT 


indication 


Handle 

Transfer result 


MLE-UNITDATA 


request 


SDU 
QoS 

Layer 2 service 
PDU priority 
Stealing permission 
Stealing repeats flag 




indication 


SDU 



The state transitions visible at these SAPs should be as shown in figure 63. 



Null 



MLE-OPEN indication 



I MLE-CLOSE indication 



MLE-REPORT indication ^ — 
MLE-UNITDATA request ( 
MLE-UNITDATA indication ^ — 



All 
Data 



Figure 63: State transition diagram of LSCL-SAP 



1 7.3.6 Service primitives for LSCL-SAP 

The service primitives at the LSCL-SAP are the following: 



MLE-CLOSE indication: this should be used by the MLE to indicate to the SCLNP entity that access to 
the communications resources has been removed and the SCLNP entity is not permitted to communicate 
with its peer entity. 
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MLE-OPEN indication: this should be used by the MLE to inform the SCLNP entity that it has access to 
the communication resources. This primitive indicates that any previous associations between peer 
SCLNP entities have not been recovered by the MLE. This primitive may be sent after recovery from a 
lower layer failure, a MLE-controlled cell change and when the MM entity has issued a MLE-OPEN 
request. 

NILE-REPORT indication: this should be used by the MLE to report on the completion of a MLE- 
UNITDATA request procedure. The result of the transfer attempt should be passed as a parameter. Errors 
detected during the MLE-UNITDATA request procedure should be indicated using this primitive. 

MLE-UNITDATA request: this should be used by the SCLNP entity to send data to a peer entity on the 
TETRA infrastructure side. Parameters indicate whether layer 2 acknowledged or unacknowledged 
service is required. 

MLE-UNITDATA indication: this should be used by the MLE to pass to the SCLNP entity data which has 
been received from a peer entity on the TETRA infrastructure side. 

1 7.3.7 Service state diagram for the LCO-S AP 

The primitives visible at the LCO-SAP should be as shown in table 218. 



Table 218: Primitives and parameters at the LCO-SAP 



Generic name 


Specific name 


Parameters 


MLE-BREAK 


indication 




MLE-CLOSE 


indication 




MLE-OPEN 


indication 




MLE-REPORT 


indication 


Handle 






Transfer result 


MLE-RESET 


request 






indication 






response 






confirm 




MLE-RESUME 


indication 




MLE-UNITDATA 


request 


SDU 




QoS 






Layer 2 service 






PDU priority 






Stealing permission 






Stealing repeats flag 




indication 


SDU 
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The state transitions visible at the LCO-SAP should be as shown in figure 64. 




Figure 64: State transition diagram of LCO-SAP 
17.3.8 Service primitives for LCO-SAP 

The service primitives at the LCO-SAP should be: 

MLE-BREAK indication: this should be used by the MLE to inform the CONP entity that the resources 
needed for communication are temporarily not available. This can be due to a lower layer failure, or due to 
a MLE-controlled cell change. 

MLE-CLOSE indication: this should be used by the MLE to indicate to the CONP entity that access to the 
communications resources has been removed and the CONP entity is not permitted to communicate with 
its peer entity. 

MLE-OPEN indication: this should be used by the MLE to inform the CONP entity that it has access to 
the communication resources. This primitive indicates that any previous associations between peer CONP 
entities have not been recovered by the MLE. This primitive may be sent after recovery from a lower layer 
failure, a MLE-controlled cell change or when the MM entity has issued a MLE-OPEN request. 

WILE-REPORT indication: this should be used by the MLE to report on the completion of a MLE- 
UNITDATA request procedure. The result of the transfer attempt is passed as a parameter. Errors 
detected during the data transfer procedures (as invoked by a MLE-UNITDATA request) are indicated 
using this primitive. 

MLE-RESET request: this primitive should be used by the CONP entity to reset the information flows of a 
MLE connection to a known state. It also applies as a CANCEL Request which deletes previous requests 
issued and not yet transmitted. 

MLE-RESET indication: this primitive should be used by the MLE to inform the CONP entity that the 
information flows of a connection must be reset to a known state. 

MLE-RESET response: this primitive should be used by the CONP entity to acknowledge that information 
flows of a connection shall be reset to a known state. 



MLE-RESET confirm: this primitive should be used by the MLE to inform the CONP entity that the 
information flows of a connection have been reset to a known state. 
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MLE-RESUME indication: this should be used to indicate that a temporary break in access to the 
communications resources has been recovered. All previous associations between peer CONP entities 
should have been successfully recovered. 

MLE-UNITDATA request: this should be used by a MLE service user to send data to a peer CONP entity 
on the TETRA infrastructure side. Parameters indicate whether a layer 2 acknowledged or 
unacknowledged service is required. 

MLE-UNITDATA indication: this should be used by the MLE to indicate to pass data which has been 
received from a peer CONP entity on the TETRA infrastructure side. 

17.3.9 Parameter summary 

The following list summarises the parameters used in the primitives described in this clause. 
Add temporary GSSI = 

GSSI. 
ASSI = 

TETRA address. 
Attached GSSIs = 

TETRA address. 

Channel change accept = 

True; 
False. 

Channel change response required = 

True; 
False. 

Circuit mode type = 

speech (TCH/S); 
unprotected data (TCH/7,2); 
low protection data (TCH/4,8), N=1 ; 
low protection data (TCH/4,8), N=4; 
low protection data (TCH/4,8) , N=8 ; 
high protection data (TCH/2,4), N=1 ; 
high protection data (TCH/2,4), N=4; 
high protection data (TCH/2,4), N=8. 

Delete temporary GSSI = 

GSSI. 
Detached GSSIs = 

TETRA address(es). 

Encryption flag = 

on; 
off. 



Endpoint identifier. 
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Energy economy mode configuration = 

Group (0-7); 
Start frame (1-18); 
Start Multiframe (1-60). 

Call release = 

True; 
False. 

Handle. 

ISSl = 

TETRA address. 

Layer 2 service = 

acknowledged request; 
acknowledged response; 
unacknowledged. 

List of GSSIs = 

TETRA address(es). 

LA. 

Minimum Mode configuration = 

Frame 18 slot (1-4). 
MCC (see 300 392-1 [11], clause 7). 
MNC (see 300 392-1 [11], clause 7). 
PDU priority = 

Eight possible values, 0...7. 

QoS = 

throughput; 
priority. 

Received TETRA address = 

TETRA address (ITSI or GTSI). 

Received address type = 

individual (ITSI); 
group (GTSI). 

Registration type = 

normal; 
forward. 
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Registration required = 

True; 
False. 

Registration Result = 

Success; 
Failure. 

SCCH configuration = 

0-11. 

SDU. 

Simplex/duplex = 

Simplex; 
Duplex. 

Stealing permission = 

Steal immediately; 
Steal when convenient; 
Stealing not required. 

Stealing repeats flag = 

Set; 
Not set. 

Subscriber class. 

Switch U-plane = 

on; 
off. 

Tx-grant = 

true; 
false. 

Transfer result = 

Success; 
Failure. 

18 MLE protocol 

18.1 Introduction 

This clause defines the protocol for the V+D MLE. This shall be the lowest sub-layer of the network layer 
as described in ETS 300 392-1 [11]. It may be used to provide sub-network services to higher network 
layer entities at the air interface according to the MLE service description (see clause 17). This clause 
defines the MLE protocol functions required for MS operation. 
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This clause specifies: 

the protocol procedures; 

the protocol services; 

the PDUs and associated elements. 
See clause 17 for the MLE service description (SAPs, services and primitives). 
1 8.2 Overview of the sub-layer 

The MLE protocol should be used to mask mobility and radio resources from the higher entities. 

It shall provide a sub-network dependent protocol (convergence) and a sub-network access protocol to 
the V+D layer 2 (see clause 20). 

18.2.1 Protocol environment 

The V+D MLE shall be the layer 3, sub-layer 3.1 which provides services to the layer 3, sub-layer 3.2, as 
shown in figure 65. This protocol shall provide services to the following higher entities: 

MM entity (see clause 1 6); 

CMCE entity (see clause 14); 

CONP entity (see clause 25); 

SCLNP entity (see clause 27). 

The MLE services shall be represented by the MLE service primitives which shall apply to the following 
SAPs: 

LCMC-SAP for CMCE; 
LCO-SAP for CONP; 
LSCL-SAP for SCLNP; and 
LMM-SAP for MM. 

The services offered at the MM SAP may interact with the services offered at the CMCE, CONP and 
SCLNP SAPs. 

The underlying protocol should be the V+D layer 2 (see clauses 22 and 23). 

The MLE protocol may also interface to the Lower Layer Management Entity (LLME) and the interface is 
defined by the C-SAP. However, the exact implementation of the interface is outside the scope of this 
ETS. 

The protocol architecture can be similar on the BS side of the air interface. 
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MM 



CMCE 



LMM-SAP 



S-CLNP 



LCMC-SAP 



CONP 



LSCL-SAP 



A 



Sublayer 
3.2 



LCO-SAP 



LAYER 3 



MLE 



TLA-SAP 



TLB-SAP 



Sublayer 
3.1 



TLC-SAP 



? ? 



Y 



LAYER 2 

Figure 65: The MLE (sub-layer 3.1) in the MS protocol stack 

The MS-MLE shall establish the basis for communication with a cell (BS) by camping on the cell and the 
MS-MLE shall check the quality using the information received from the layer 2. Once the cell has been 
found suitable by the MS-MLE, the MM entity may intervene in order to register the MS. When the cell has 
been registered, the MS is said to be attached and the MLE can now offer data transfer services to the 
CMCE, CONP and SCLNP entities as well. Data transfer shall be regulated by the MM entity which may 
allow access for MM only or for all entities. 

The MLE shall perform surveillance of the quality of the radio communication path. It may report any break 
or loss of the path and, when necessary it should try to re-establish the communication with the same or 
another BS in either the same or a different LA. 

1 8.2.2 Services and primitives offered by the MLE to the MM entity 

The services and primitives offered to the MM entity are described in clause 17. 
The services offered shall be: 

a) activation of MLE procedures: 

MLE-ACTIVATE request/confirm/indication; 

b) opening of link access to other layer 3 entities: 

MLE-OPEN request; 
data transfer: 



c) 



d) 



e) 



MLE-UNITDATA request/indication; 
MLE-REPORT indication; 

closing the access to other entities: 

MLE-CLOSE request; 
deactivation of the MLE procedures: 

MLE-DEACTIVATE request; 
receiving information on a cell or LA: 



MLE-LINK indication; 
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g) updating current registered area: 

MLE-UPDATE request; 

h) cancellation of issued primitive requests: 

MLE-CANCEL request. 

i) locking MLE while MM signalling exchange is in progress: 

MLE-BUSY request; 
j) releasing MLE after completion of MM signalling exchange: 

MLE-IDLE request; 
k) performing forward registration during cell re-selection: 

MLE-PREPARE request/confirm; 

I) lower layer management: 

MLE-IDENTITIES request; 
MLE-INFO request. 

1 8.2.3 Services and primitives offered by the MLE to the CMCE entities 

The services and primitives offered to the CMCE entity are described in clause 17. 
The services offered shall be: 

a) indication that access to resources is enabled: 

MLE-OPEN indication; 

b) indication that access to resources is disabled: 

MLE-CLOSE indication; 

c) indicating a temporary break in the access to the communication resources: 

MLE-BREAK indication; 

d) indicating resumption (or reopening) in the access to the communication resources: 

MLE-RESUME indication; 
MLE-REOPEN indication; 

e) restoration of circuit mode calls after cell re-selection: 

MLE-RESTORE request/confirm; 

f) data transfer: 

MLE-UNITDATA request/indication; 
MLE-REPORT indication; 

g) cancellation of issued primitive requests: 

MLE-CANCEL request; 
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h) lower layer management: 

MLE-CONFIGURE request; 
MLE-IDENTIT1ES request. 

18.2.4 Services and primitives offered by the NILE to the SCLNP entity 

The services and primitives offered to the SCLNP entity are described in clause 17. 
The services offered shall be: 

a) indication that access to resources is enabled: 

MLE-OPEN indication; 

b) indication that access to resources is disabled: 

MLE-CLOSE indication; 

c) data transfer: 

MLE-UNITDATA request/indication; 
MLE-REPORT indication. 

18.2.5 Services and primitives offered by the NILE to the CONP entity 

The services and primitives offered to the CONP entity are described in clause 17. 
The service offered shall be: 

a) indication that access to resources is enabled: 

MLE-OPEN indication; 

b) indication that access to resources is disabled: 

MLE-CLOSE indication; 

c) indicating a temporary break in the access to the communication resources: 

MLE-BREAK indication; 

d) indicating resumption in the access to the communication resources: 

MLE-RESUME indication; 

e) reset procedures: 

MLE-RESET request/indication/response/confirm; 

f) data transfer: 

MLE-UNITDATA request/indication; 
MLE-REPORT indication; 

g) cancellation of issued primitive requests: 

MLE-CANCEL request. 
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18.2.6 Services and primitives offered by layer 2 to MLE 

Layer 2 shall provide the MLE with different services, which enable the MLE to provide the services 
requested by its services users. The following primitives are defined for that purpose: 

On the TLA-SAP the following services and primitives should be available (see clause 20 for service 
definitions): 

a) establishing a data link connection by using the LLC advanced link mechanism: 

TL-CONNECT request/indication/response/confirm; 

b) transfer of data using a Layer 2 acknowledged service: 

TL-DATA request/indication/response/confirm; 

c) disconnection of an established data link connection, i.e. an LLC advanced link: 

TL-DISCONNECT request/indication/confirm; 

d) transfer of data using a Layer 2 unacknowledged service: 

TL-UNITDATA request/indication; 

e) receive report information on the progress of issued request primitives and unrecoverable 
transmission errors detected in the data link: 

TL-REPORT indication; 

f) cancellation of issued request primitives: 

TL-CANCEL request. 

On the TLB-SAP the following services and primitives should be available, see clause 20 for service 
definitions: 

a) reception of layer 3 information in the synchronisation broadcast and system information broadcast. 
The broadcast shall be recognised by layer 2 and forwarded to layer 3 as SDU elements inside 
primitives: 

TL-SYNC indication; 
TL-SYSINFO indication. 

18.2.7 Services and primitives between the MLE and the LLME 

The LLME may be used for exchanging layer-to-layer information. In the protocol stack (see figure 65) the 
access to the LLME is modelled in the TLC-SAP. 

The following primitives should be defined for this SAP: 

a) control of scanning (MS side only): 

TL-SCAN request/confirm; 
TL-SCAN-REPORT indication; 

b) selecting cell for attachment (MS side only): 

TL-SELECT request/indication/confirm; 

c) control of monitoring (MS side only): 

TL-MONITOR-LIST request; 
TL-MONITOR indication; 
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d) receive quality information on the serving cell (MS side only): 

TL-MEASUREMENT indication; 

e) receive path loss information (MS side only): 

TL-REPORT indication; 

f) set-up and configure layer 2 according to commands from service SAP users (MS side only): 

TL-CONFIGURE request/confirm. 
1 8.2.8 Protocol sequences 

The basic protocol primitive sequences are shown in figures 66 to 68. The operation of the protocol should 
be modelled as a finite state automaton governed by a state variable. A transition of the automaton should 
be prompted by the occurrence of an event at one of three interfaces: 

a) the interface to any of the service users (MM, CMCE, CONP, SCLNP); 

b) the interface to the underlying service which is the V+D Layer 2; 

c) the interface to the LLME. 



LSCL mobile SAP 



Opening or closing 
of network access 



MLE-OPEN indic ^on 
MLE-CLOSE indication 



i^ti 



LSCL SwMI SAP 



MLE-OPEN indication 
> 



MLE-CLOSE indication 

— > 



Data transfer 

MLE-UNITDATA reques^ 
MLE-REPORT indication 



MLE-UNITDATA indication 
> 



Figure 66: Primitive time sequence at the LSCL-SAP 



Initialisation, re-initialisation 
and activation of MLE 

MLE-ACTIVATE indication 
< 



MLE-ACTIVATE re quest 



MLE-ACTIVATE confirm 



ntifn 



Deactivation of MLE 



MLE-DEACTIVATE request 



Open or close network access 
MLE-OPEN request 



MLE-CLOSE request_ 



Registration , Intervention 



MLE-LINK indication 



MLE-UPDATE req uest 

Data transfer 

MLE-UNITDATA re quest 



MLE-REPORT indication 



Restrict channel allocations 
on incoming group calls 

MLE-BUSY request^ 
MLE-IDLE request 
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LMM mobile SAP LMM SwMI SAP 



MLE-UNITDATA indication 



Figure 67: Primitive time sequence at the LMM-SAP 
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LCMC and LCO mobile SAPs LCMC and LCO SwMI SAPs 



Break, resum e and reopen 
communication on a MLE connection 

MLE-BREAK indication 

< — 

MLE-RESUME indication 
< 

MLE-REOPEN indication 
< 

Reset an information flow (LCO only) 

MLE-RESET request : 



MLE-RESET confirm^ 



Opening or <?lpsing 
of network access. 



MLE-OPEN indic ^on 
MLE-CLOSE indication 



MLE-BREAK indication 

— > 

MLE-RESUME indication 
> 

MLE-REOPEN indication 
> 



MLE-RESET indication 
> 



MLE-RESET response 



MLE-OPEN indication 
> 



MLE-CLOSE indication 

— > 



Data transfer 

MLE-UNITDATA re quest y 



MLE-REPORT indication 



MLE-UNITDATA indication 
> 



Restore a circuit mode call (LCMC only) 



MLE-RESTORE re quest 



MLE-RESTORE confii 



MLE-RESTORE indication 

— > 



MLE-RESTORE response 



Figure 68: Primitive time sequence at the LCMC- and LCO-SAP 
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18.3 MLE functions 
18.3.1 Overview 

The MLE functional groups are shown in figure 69. 



CMCE 




CONP 











SCLNP 







LCMC-SAP |— | LC0^SAP1 ~ 4LSCCSAP 



MM 



■ILMM-SAP ' 



Attachment 
Management 



r 



Network 
Broadcast 



Data Transfer 



MLE 



TLA-SAP h 



Management 
Entity (TMI) 



- [TLB-SAP 



TLC-SAP 



Layer 2 

Figure 69: MLE functional model 

The MLE functional entities are: 
a) attachment management: 

management of monitoring and scanning procedures; 

surveillance of the serving cell quality; 

management of the ranking procedure; 

management of the cell relinquishable, improvable and usable radio criteria; 
management of the roaming announcements and declarations; 

informing upper entities CMCE and CONP of broken and restored MLE connections via the 
data transfer sub-entity; 
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b) data transfer: 

selection of underlying LLC service; 
address handling (ISSI, GSSI and TMI); 

informing the upper entities CMCE, CONP and SCLNP of enabled and disabled access to 
the communication resources; 

routing and multiplexing to layer 2 service end points (including addition/removal of MLE 
protocol control information); 

routing and multiplexing to MLE SAPs and other MLE functional entities; 
quality of service mapping (e.g. priority, throughput, transfer service); 

c) network broadcast: 

formatting and broadcasting of the network information (SwMI); 
reception and analysis of network information (MS/LS); 

configuring of MAC layer 2 with synchronisation and system information broadcast. 

d) management: 

handling network management procedures, e.g. addressed to the TETRA Management 
Identity (TMI); 

handling local management information from the management entity to the lower layers. 

18.3.2 Access to the communication resources and activation of the MLE 

Access to all communication resources is controlled by the MLE, according to requests received from the 
MM entity. 

At power on, or other start-up, there is no requirement that the MLE shall have any prior knowledge of the 
suitability of any cell. In order that the MS can communicate, the MLE shall select a suitable cell. A 
suitable cell should be one in which the MS can reliably decode down link data, which has a high 
probability of uplink communication and that the MS may request and obtain service. 

The procedures defined in the following paragraphs describe methods by which the MS can select a cell. 

The MLE cell selection procedure is initiated by the MM entity defining the cell selection criteria (e.g. 
mobile network identity) in an MLE-ACTIVATE request primitive. When a suitable cell has been found the 
MLE issues an MLE-ACTIVATE confirm primitive to the MM to report the cell details. Initially the radio 
communications link may only be used for MM data transfer until the MM issues an MLE-OPEN request 
primitive thereby instructing the MLE to open access to the layer 3 entities. The MM entity issues the 
MLE-OPEN request after completion of any MM procedures (e.g. registration). An MLE-OPEN request is 
received by both the attachment management and the data transfer sub-entities within the MLE. The 
opening of link access is reported to the CMCE, CONP and SCLNP with an MLE-OPEN indication 
primitive. 

NOTE: If no MM procedures are required, the MM may issue the MLE-OPEN request 
immediately after the MLE-ACTIVATE confirm is received. 

The MLE on the MS side can take the decision to change cell from measurement processing and 
threshold comparisons. MM shall be informed with an MLE-LINK indication in the event that the cell re- 
selection results in the selection of a cell in a LA that is not in the current registration area. The 
parameters associated with the MLE-LINK indication inform the MM of the LA f MNC and MCC of the new 
cell. 
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1 8.3.3 Deactivation of the MLE 

Upon receipt of an MLE-DEACTIVATE request the MLE shall cease all functions. The MLE-DEACTIVATE 
should be preceded by an MLE-CLOSE request to the data transfer sub-entity. 

1 8.3.4 Attachment management sub-entity 

The attachment management sub-entity shall be responsible for the initial cell selection and cell 
re-selection procedures. The initial cell selection and cell re-selection procedures comprise the functions 
listed below. These following functions shall be activated at power on: 

management of the monitoring and scanning procedures; 

surveillance of the serving cell quality; 

management of the neighbour cell ranking procedure; 

management of the cell re-selection criteria; 

management of the cell re-selection announcements and declarations; 

informing upper entities CMCE and CONP of broken and restored MLE connections via the data 
transfer sub-entity. 

Cell selection and re-selection shall only be carried out using the individual or alias subscriber identities. 
Cell re-selection shall not be carried out using group addresses. Any cell re-selection messages received 
on a GSSI shall be ignored. 

Where the MS is engaged in more than one call, the MS shall only apply the cell re-selection procedures 
once and not for each call in progress. Once a cell has been re-selected the CMCE may restore the calls. 

18.3.4.1 Scanning of cells 

Scanning is where an MS is synchronised to a cell, directly measures the received power of that cell and 
directly obtains the broadcast and synchronisation information for that cell by decoding the BNCH and 
BSCH. The scanning sub-function enables the MLE to directly obtain the path loss measurements from 
the cells. To obtain the C1 path loss parameter from layer 2, the MS-MLE shall per cell issue a TL-SCAN 
request primitive to the TLC-SAP along with the parameters indicating which cell is to be scanned. 

The MS-MLE shall know locally which channels the MS is capable of scanning and shall not instruct the 
lower layers to scan any channel that the MS-MLE knows to be outside the capabilities of the equipment. 
When layer 2 has completed scanning of one cell, the C1 path loss shall be part of the report parameter of 
the TL-SCAN confirm primitive or of the TL-SCAN-REPORT indication primitive, both given by layer 2. 
The C1 formula is defined in clause 23. The MS-MLE can use the list of neighbour cells in the 
D-NWRK-BROADCAST PDU to specify which channels to be scanned. 

There are three types of scanning defined in clause 23. These are: 

foreground, where scanning is the only activity; 

background, where communications with the current serving cell are maintained in parallel with the 
scanning, and the scanning causes no interruption to that service; 

interrupting, where communications with the current serving cell are maintained in parallel with the 
scanning, but the scanning causes limited interruptions to that service. 

Scanning shall have been performed within the last 60 seconds for a scanning measurement to be 
considered valid. 
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18.3.4.2 Monitoring of neighbour cells 

Monitoring is where the MS calculates the path loss parameter C2 of neighbour cells using information 
about the neighbour cells broadcast by the serving cell. It differs from C1 in that the serving cell provides 
the cell selection parameters for the neighbour cell. However, the MS is still required to directly measure 
the received power of the neighbour cell. 

In order to be able to monitor the neighbour cells the MS-MLE shall have received a 
D-NWRK-BROADCAST PDU containing a list of the neighbour cells. The procedures concerning network 
broadcast PDUs are dealt with in subclause 18.3.6. Once the network broadcast information has been 
received, the monitoring can be started by issuing a TL-MONITOR-LIST request primitive through the 
TLC-SAP. The TL-MONITOR-LIST request primitive informs layer 2 of the cells to be monitored. The 
parameters passed down with the TL-MONITOR-LIST shall be a list of channels. The MS-MLE shall know 
locally which channels the MS is capable of monitoring and shall not instruct the lower layers to monitor 
any channel that the MS-MLE knows to be outside the capabilities of the equipment. For each channel the 
lower layers return a TL-MONITOR indication containing the C2 path loss parameter. C2 is defined in 
clause 23. 

Monitoring is a background procedure and is defined in clause 23. Monitoring shall have been performed 
during the last 60 seconds for a monitoring measurement to be considered valid. 

If it is required to stop the monitoring process, the MLE shall issue a TL-MONITOR-LIST with an empty list 
as parameter. 

18.3.4.3 Surveillance of the serving eel! 

Surveillance is the procedure whereby the MS analyses the received information on the quality of the link 
to the serving cell. Once the MS-MLE has chosen the serving cell, the MLE shall select that cell by issuing 
a TL-SELECT request primitive to the TLC-SAP. Once the cell has been selected the lower layers return a 
TL-SELECT confirm and periodically send TL-MEASUREMENT indication primitives containing the C1 
path loss parameter for the serving cell. The C1 path loss parameter is described in clause 23. 
Additionally the surveillance sub-function shall be responsible for the analysis of any network broadcast 
information received from the serving cell via the network broadcast sub-entity. 

Should the MLE receive a TL-REPORT indication from the lower layers indicating that the path to the 
serving cell has been lost then it shall inform the upper entities CONP and CMCE by issuing an 
MLE-BREAK indication via the data transfer sub-entity. TL-REPORT indicates that the path has been lost 
if the uplink or downlink have failed, or, the maximum path delay has been exceeded (uplink failure and 
maximum path delay exceeded can only be indicated to the MS in a MAC-RESOURCE PDU from the 
SwMI). 

If the MLE receives a TL-SELECT indication via the TLC-SAP, outside of cell re-selection, indicating that 
the MAC has been instructed to change channels and no response is required, the surveillance function 
shall note the new serving cell channel. 

1 8.3.4.4 Ranking of neighbour cells 

The ranking sub-function can use the path loss measurements, C1 and C2 t to maintain a ranked list of 
neighbour cells. 

The ranking algorithm shall rank the neighbour cells which have been monitored or scanned in strict order 
of downlink radio connection quality. The results of this algorithm can be used to determine when a cell is 
deemed to be radio usable, radio relinquishable or radio improvable according to subclause 18.3.4.7. The 
use of a ranking algorithm based only on C1 or C2 is essential in order to facilitate network coverage 
planning. 
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A cell shall meet the following minimum criteria in order to be included in the ranking list of neighbour 
cells: 

C1 > 0 or C2 > 0; 

if the neighbour is outside of the current registration area, the neighbour cell shall support roaming 
(which is broadcast as part of the BS service details element); 

NOTE: The current registration area consists of all of the LAs in which the MS is currently 
registered. 

if the neighbour cell has a different MCC or MNC, the neighbour cell shall support migration (which 
is broadcast as part of the BS service details element). 

If these criteria are not satisfied, an MS shall not include that cell in the ranking list and so shall not 
consider that cell for cell re-selection. 

If the information about the LA or MCC or MNC is not broadcast by the serving cell as part of the 
neighbour cell information, the MS may assume that is it is free to include that cell in its ranking list 
provided the C1 > 0 or C2 > 0 criterion is met. 

An MS can build a valid ranking list by obtaining the cell re-selection parameters for the neighbour cells 
from the D-NWRK-BROADCAST PDU transmitted on the serving cell. In this case, the MS shall monitor 
the neighbour cells specified by D-NWRK-BROADCAST and shall calculate C2 for each one using the cell 
re-selection parameters for the neighbour cell sent in D-NWRK-BROADCAST on the serving cell. A valid 
ranking list can then be derived using the C2 measurements. 

An MS can also build a valid ranking list by scanning the neighbour cells to obtain the cell re-selection 
parameters directly. In this case, the MS shall calculate C1 for each of the neighbour cells and shall derive 
a valid ranking list using the C1 measurements. 

18.3.4.4.1 Ranking of monitored cells 

Ranking of monitored neighbour cells shall be based upon the received path loss parameter C2 from the 
layer 2 monitoring process, issued in a TL-MONITOR indication primitive. 

The ranking should produce a ranked cell list which can be used as a scanning list, if the scanning 
function is applied. This ranked cell list may be used for making the decision of whether and when to 
change cell, according to subclause 18.3.4.7. 

1 8.3.4.4.2 Ranking of scanned cells 

Ranking of scanned neighbour cells shall be based upon the received path loss parameter C1 from the 
layer 2 scanning process, issued in a TL-SCAN confirm primitive or a TL-SCAN-REPORT indication 
primitive. 

The ranking should produce a ranked cell list which may be used for making the decision of whether and 
when to change cell, according to subclause 18.3.4.7. 

1 8.3.4.5 Criteria used during cell re-selection 

The following subclauses define the criteria which shall be used to initiate the cell re-selection procedures 
described in subclause 1 8.3.4.6. 

1 8.3.4.5.1 Criterion for starting the monitoring process 

The monitoring process may be permanently enabled or enabled only when some criterion is met, e.g. the 
serving cell ceases to support the service level required by the MS, or the serving cell quality falls below a 
pre-determined threshold. In the latter case it is assumed that the monitoring process would be disabled 
when the serving cell quality rises above the threshold plus some hysteresis factor. 
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The exact method for the selection of the thresholds and hysteresis values is outside the scope of this 
ETS. 

Where the monitoring process is not permanently enabled and the MS-MLE receives system broadcast 
information informing it that the service level required by that MS is no longer supported, e.g. that the 
subscriber class that the MS belongs to is no longer able to access the system, the monitoring process 
should be started. 

Where the monitoring process is not permanently enabled, but started when a threshold value is crossed, 
the threshold value should be chosen to be a value greater than the threshold parameters, 
FAST_RESELECT_THRESHOLD, SLOW_RESELECT_TH RES HOLD, to allow the MS enough time to 
successfully select a new cell prior to the complete loss of service from the current serving cell. 

1 8.3.4.5.2 Criterion for starting scanning 

The individual criteria for starting scanning in the different selection and re-selection procedures are 
defined in subclauses 18.3.4.5. and 18.3.4.6.1 to 18.3.4.6.5. 

1 8.3.4.5.3 Criterion for radio link failure 

Radio (ink failure occurs when the quality of the uplink or downlink radio connection falls below a certain 
level. A radio link failure shall be declared if any of the following events occur: 

layer 2 declares C1 path loss parameter failure (C1 < 0 or AACH decoding failure as described in 
clause 23) for the serving cell via the TL-REPORT indication primitive (down link failure); 

an error is reported via the TL-REPORT indication primitive indicating either that the maximum path 
delay has been exceeded or that an uplink failure has occurred; both of these conditions can be 
reported to the MS MAC from the SwMl in a MAC-RESOURCE PDU. 

1 8.3.4.5.4 Criterion for radio relinquishable cell 

A serving cell becomes radio relinquishable when the quality of the downlink radio connection falls below a 
certain level and there is a neighbour cell which has a downlink radio connection of sufficient quality. The 
following conditions shall be met simultaneously in order to declare the serving cell radio relinquishable: 

the serving cell path loss parameter C1 shall for a period of 5s fall below 
FAST_RESELECT_THRESHOLD; 

the path loss parameter, C1 or C2, of at least one of the neighbour cells in the ranking list shall 
exceed by FAST_RESELECT_HYSTERESIS the path loss parameter, C1, of the current serving 
cell for a period of 5s; 

no cell re-selection shall have taken place within the previous 15 seconds. 

The MS-MLE shall check the criterion for serving cell relinquishment as often as one neighbour cell is 
scanned or monitored. 

1 8.3.4.5.5 Criterion for radio improvable cell 

A serving cell becomes radio improvable when the quality of a neighbour cell downlink radio connection 
exceeds that of the serving cell by a certain amount. The following conditions shall be met simultaneously 
in order to declare the serving cell radio improvable: 

the serving cell path loss parameter, C1 shall, for a period of 5 s, fall below 
SLOW.RESELECTTHRESHOLD; 

the path loss parameter, C1 or C2, of at least one of the neighbour cells in the ranking list shall 
exceed by SLOW_RESELECTJHYSTERESIS the path loss parameter, C1, of the current serving 
cell for a period of 5 s; 

no cell re-selection shall have taken place within the previous 1 5 s. 
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The MS-MLE shall check the criterion for improving the serving cell as often as one neighbour cell is 
scanned or monitored 

18.3.4.5.6 Criterion for radio usable cell 

A neighbour cell becomes radio usable when it has a downlink radio connection of sufficient quality. The 
following condition shall be met in order to declare a neighbour cell radio usable: 

the neighbour cell shall for a period of 5s have a path loss parameter, C1 or C2, which is greater 
than (FAST_RESELECT_THRESHOLD + FAST_RESELECT_HYSTERESIS); 

no cell re-selection shall have taken place within the previous 15 s. 

The MS-MLE shall check the criterion for a neighbour cell being usable each time the neighbour cell is 
scanned or monitored 

1 8.3.4.5.7 Criteria for initiating the cell re-selection procedures 

Cell re-selection shall be initiated if a neighbour cell is declared radio improvable (as defined in subclause 
18.3.4.7.5) and the service criteria as defined below are the same on both the serving cell and the radio 
improvable neighbour cell. If the service provided by the neighbour cell is lower than that provided by the 
serving cell, the cell re-selection may be postponed until the serving cell is declared radio relinquishable 
(as defined in subclause 18.3.4.7.4). If the service provided by the neighbour cell is higher than that 
provided by the serving cell, then the cell re-selection may be performed as soon as the neighbour cell is 
declared radio usable (as defined in subclause 18.3.4.7.6). 

The following service criteria may be used to compare the service provided by a serving cell and a 
neighbour cell: 

support for subscriber class (broadcast as part of D-MLE-SYSINFO PDU); 

priority cell indication (broadcast as part of the BS service details element); 

support for TETRA standard speech (broadcast as part of the BS service details element); 

support for TETRA circuit mode data (broadcast as part of the BS service details element); 

support for CONP (broadcast as part of the BS service details element); 

support for SCLNP (broadcast as part of the BS service details element); 

support for air interface encryption (broadcast as part of the BS service details element); 

cell service level (broadcast as part of D-MLE-SYNC PDU); 

whether or not the current serving cell or LA is preferred over the neighbour cell (which may stored 
in the MS at subscription); 

whether or not a circuit mode call or C-pIane signalling transfer is in progress. 

The BS service details element and the cell service level are broadcast in the MLE-SYSINFO PDU 
(transmitted on BNCH) and MLE-SYNC PDU (transmitted on BSCH) respectively for the serving cell, and 
in the D-NWRK-BROADCAST for the neighbour cells. BSCH and BNCH shall be transmitted on the 
serving cell and D-NWRK-BROADCAST may be transmitted on the serving cell. 
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Using the above criteria, an MS may decide whether or not a neighbour cell can be considered to offer 
better service than the current serving cell. The following conditions shall cause the MS to rate a 
neighbour cell to have better service than the current serving cell: 

the MS subscriber class is supported on the neighbour cell but not on the serving cell; 

the neighbour cell is a priority cell and the serving cell is not a priority cell; 

the neighbour cell supports a service (i.e. TETRA standard speech, circuit mode data, CONP or 
SCLNP) which is not supported by the serving cell and the MS requires that service to be available; 

the neighbour cell supports air interface encryption which is not supported by the serving cell and 
the MS requires that air interface encryption is available; 

the cell service level indicates that the neighbour cell is more lightly loaded than the serving cell; 
the neighbour cell is a preferred cell (or "home cell") or belongs to a preferred LA. 

In these cases the MS may choose to initiate cell re-selection as soon as the neighbour cell becomes 
radio usable as defined in subclause 18.3.4.7.6. If there is more than one neighbour cell which is radio 
usable, the MS should choose the one which gives has the highest ranking in the ranking list and which 
best satisfies the service requirements for the MS. 

The following conditions shall cause the MS to rate a neighbour cell to have lower service than the current 
serving cell: 

the MS subscriber class is not supported on the neighbour cell but is supported on the serving cell; 
the serving cell is a priority cell and the neighbour cell is not a priority cell; 

the serving cell supports a service (i.e. TETRA standard speech, circuit mode data, CONP or 
SCLNP) which is not supported by the neighbour cell and the MS requires that service to be 
available; 

the serving cell supports air interface encryption which is not supported by the neighbour cell and 
the MS requires that air interface encryption is available; 

the cell service level indicates that the serving cell is loaded more lightly than the neighbour cell; 
the serving cell is a preferred cell (or "home cell") or belongs to a preferred LA. 

In these cases the MS may postpone cell re-selection until the serving cell becomes radio relinquishable 
as defined in subclause 18.3.4.4. If there is more than one neighbour cell which causes the serving cell to 
be radio relinquishable, the MS should choose the highest ranked cell in the ranking list which satisfies the 
service requirements for the MS. 

If the neighbour cell is deemed to offer neither better service or lower service over the serving cell, the 
service shall be deemed to equal and the MS shall initiate the cell re-selection procedures as soon as a 
neighbour cell becomes radio improvable over the current serving cell as defined in subclause 18.3.4.7.5. 
A neighbour cell shall be deemed to be equal with respect to the above service criteria if the information is 
not available for either the serving or neighbour cell e.g. the cell service level may not be included in the 
D-NWRK-BROADCAST PDU causing the service to be deemed equal with respect to cell service level. 

If a neighbour cell is deemed to provide equal or better service than the current serving cell, the cell 
re-selection may be postponed if there is a circuit mode call or ongoing signalling currently in progress. In 
this case, the cell re-selection may be postponed until the serving cell becomes radio relinquishable, even 
if there are neighbour cells which meet the radio improvable or radio usable criteria. 

If radio link failure occurs (which can occur if there are no neighbour cells of sufficient radio connection 
quality to make the serving cell relinquishable), the MS may re-select any neighbour cell in the ranking list 
whose path loss parameter, C1 or C2, is greater than zero. If there are multiple cells in the ranking list 
which meet this radio criterion, the MS should choose the highest ranked cell which satisfies the service 
requirement for the MS. If there are no cells which meet this minimum radio criterion, the initial cell 
selection procedure shall be invoked. 
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1 8.3.4.6 Initial cell selection 

The MS shall implement the initial cell selection procedure when the MS-MLE receives an 
MLE-ACTIVATE request from MM e.g. when not attached to a cell, at power on, or after a previous 
deactivation has taken place. The exact detailed implementation of the procedure and any associated 
algorithms is outside the scope of this ETS. The MS shall be required to fulfil certain conditions as stated 
below. The procedure shall be referred to as the "initial cell selection" procedure. This does not imply that 
the procedure shall necessarily be different from any procedures applied for cell re-selection. 

The initial cell selection procedure shall ensure that the MS selects a cell in which it can reliably decode 
down link data and which has a high probability of uplink communication. The minimum conditions that 
shall have to be met are that C1 > 0. Access to the network shall be conditional on the successful 
selection of a cell. 

The procedure shall be initiated by the receipt of the MLE-ACTIVATE request primitive from the MM entity. 
This primitive has parameters which include the MCC and the MNC of the particular network which the 
MS should select. The MS-MLE shall then use this information, and initiate the foreground scanning 
procedure and thus obtain the path loss parameter C1 and the network broadcast information for each 
cell. This information can be used to produce a list of preferred cells. These cells shall then be ranked by 
the MS-MLE. The ranking algorithm is outside the scope of this ETS. 

In the event that there are no suitable cells available when all cells in the list have been scanned, the MLE 
shall inform the MM entity with an MLE-ACTIVATE indication that no suitable cell has been found. The 
MLE shall continue the scanning of cells until a suitable cell is found, or until the MS is powered down. The 
exact procedures, algorithms and parameters applied for the continued scanning of cells are outside the 
scope of this ETS. 

The MS shall select a cell which has C1 > 0. The MS should choose the cell which has the highest ranking 
according to the initial cell selection ranking procedure. 

NOTE: The initial cell selection ranking procedure is not defined by this ETS. 

The cell shall be selected by issuing a TL-SELECT request primitive to the TLC-SAP. The parameters of 
the TL-SELECT request inform the lower layers of the channel and the parameters, 
MS_TXPWR_MAX_CELL and RXLEV_ACCESS_MIN for the cell. Once the cell has been selected the 
lower layers return a TL-SELECT confirm. The MLE shall issue an MLE-ACTIVATE confirm to the MM. If 
registration is required in the cell, the MM shall then register. If the registration is successful or if no 
registration is required, the MLE may receive an MLE-UPDATE request from MM supplying information 
regarding updated search areas for further monitoring. 

In the event that the initial cell selection is unsuccessful as a result of registration or authentication failure, 
MM shall instruct the MLE attachment management sub-entity, using an MLE-UPDATE request, to 
suspend the ranking of that cell. This shall result in the selection of a different cell by the MLE, unless all 
opportunities have been used, in which case MM shall close the MLE service. 

Upon receipt of the MLE-OPEN request, the MLE shall send MLE-OPEN indication to the higher layer 3 
entities, CMCE, CONP and SCLNP and shall initiate the serving cell surveillance procedures for the new 
cell as defined in subclause 18.3.4.3 and may also initiate monitoring or background/interrupting scanning 
of neighbour cells. 

18.3.4.7 Cell re-selection 

This subclause defines the overall process of the cell re-selection procedure. 

The cell re-selection procedure shall ensure that the MS selects a cell in which it can reliably decode down 
link data and in which it has a high probability of uplink communication according to the criteria in 
subclause 18.3.4.7. The minimum conditions which shall have to be met are that C1 > 0 and, in the case 
of an MS in a circuit mode call that the maximum path delay is not exceeded. 

NOTE: The SwMI informs the MS that maximum path delay is exceeded in a 
MAC-RESOURCE PDU. 
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If the cell re-selection procedure is unsuccessful, such that the MLE is left with no usable radio channels, 
the MS-MLE shall indicate this to the MM using an MLE-ACTIVATE indication. MM may give further 
instructions, e.g. new LAs, or, if all opportunities have been used, MM shall close the MLE services (see 
clause 16). When the MM eventually opens up the services again, MS-MLE shall be activated and the 
initial cell selection procedures as specified in subclause 18.3.4.5 shall apply. 

Cell re-selection can be performed by the MS-MLE when a MS is attached to a cell in idle or traffic mode. 
The procedure can handle the following categories as listed below: 

undeclared; 
unannounced; 
announced type 3; 
announced type 2; 
announced type 1 . 

Undeclared cell re-selection is performed by the MLE when there are no calls in progress, and therefore 
requires no MLE signalling between the MS and the SwMI. 

Unannounced cell re-selection is used when the MS is unable to or, in the case of listening to group calls, 
has no need to send the announcement signalling to the serving cell prior to performing the cell 
re-selection. The MS may attempt to recover the CMCE and CONP connections on the new cell. 

Announced cell re-selection is used when the MS informs the serving cell prior to the cell change, and 
attempts to restore the call(s) upon arrival at the new serving cell. This maximises the probability of 
restoring the CMCE and CONP connections on the new cell. Announced cell re-selection is divided into 
three categories to reflect different levels of SwMI and MS functionality. 

Type 3 re-selection is provided for MSs which are unable to perform background scanning of a selected 
neighbour cell, and which must therefore break the call(s) for a period and perform foreground scanning in 
order to acquire broadcast and synchronisation information for the new cell. Upon selecting the new cell, 
call restoration signalling can be used to restore the call(s). 

Type 2 re-selection requires that the MS is able to perform background scanning of a selected neighbour 
cell, and is therefore in a position to immediately switch to the new cell. In type 2 the MS selects the 
MCCH on the new cell to perform call restoration signalling and may then be allocated a traffic channel 
upon successful completion of this signalling. 

Type 1 re-selection requires that the MS is able to perform background scanning, and that the SwMI is 
able to direct the MS from the traffic channel on the original cell directly the MCCH or to a traffic channel 
on the new cell. 

Unannounced and the three types of announced cell re-selection shall apply to an MS engaged in a circuit 
mode call or in a connection-oriented data transfer. 

All MS-MLE shall support undeclared, unannounced and announced type 3 cell re-selection. An MS-MLE 
may also support announced type 2 and announced type 1 cell re-selection. It is not necessary for the 
SwMI to know which type of cell re-selection procedures the MS can support in order for these procedures 
to work. The MS shall determine which types of re-selection are supported by the SwMI from the 
neighbour cell information element transmitted in the D-NWRK-BROADCAST PDU. 

If the SwMI does not support neighbour cell information in the D-NWRK-BROADCAST transmission (see 
subclause 18.3.6), the SwMI shall only be able to support undeclared, unannounced and announced type 
3 cell re-selection. 

If the SwMI supports neighbour cell information in the D-NWRK-BROADCAST transmission, the MS shall 
only attempt cell re-selection to a neighbour cell contained in the D-NWRK-BROADCAST PDU. 



All MLE re-selection signalling shall be sent via the TLA-SAP using the basic link acknowledged service. 
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1 8.3.4.7.1 Determination of which type of re-selection to apply 

The decision tree for deciding which cell re-selection type to use is shown in Figure 70. 
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Figure 70: Decision tree to choose re-selection type 

The MS shall normally perform cell re-selection as a result of building a ranking list from monitoring or 
scanning of neighbour cells. From the neighbour cell measurements, one of the cell re-selection criteria 
defined in subclause 18.3.4.7 may be met causing cell re-selection to be initiated. The cell chosen as the 
one to which the MS will attempt to select is known as the preferred neighbour cell. 

In the case where the MS has knowledge of the neighbour cells (e.g. from the D-NWRK-BROADCAST 
PDU or from scanning or pre-programmed at subscription), but has not yet built a valid ranking list, radio 
link failure may occur or the maximum path delay may be exceeded. If this happens, the MS shall apply 
undeclared cell re-selection if not currently participating in a circuit mode call or connection-oriented data 
transfer. If the MS is participating in a call or data transfer, the MS shall apply unannounced cell re- 
selection. 



If the MS has no knowledge of neighbour ceils, the MS should apply initial cell selection procedures, but 
shall not attempt to restore a call on restoration of the radio link. 
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The MS shall initiate cell re-selection subject to the criteria specified in subclause 18.3.4.7. It shall 
determine which type of re-selection is to be applied from figure 70. The type of re-selection to be 
employed shall depend on the following criteria: 

whether or not a circuit mode call or CONP transfer is in progress; 

whether the call is an individual or group call; 

whether or not transmit permission has been granted; 

whether or not the MS has scanned the preferred neighbour cell. 

The cell re-selection procedure shall be initiated after the MS has built a valid ranking list and one of the 
cell re-selection criteria as defined in subclause 18.3.4.7 has resulted in selection of a preferred neighbour 
cell. An MS shall scan the preferred neighbour cell before it can select that cell. If the MS can perform 
background scanning of a preferred neighbour cell, then it may attempt to use announced type 1 or 2 cell 
re-selection. Otherwise, the MS shall use unannounced or announced type 3 cell re-selection. 

The MS may choose to use type 1 or type 2 cell re-selection according to the capabilities of the SwML If 
the SwMI does not support announced cell re-selection types 1 or 2 (as indicated in the serving cell 
information element broadcast as part of the D-NWRK-BROADCAST PDU), the MS shall choose the type 
of cell re-selection with the smallest number which is supported by the SwMI. 

For example, if the MS chooses announced type 1 cell re-selection according to the decision tree, and the 
SwMI supports only announced type 3, then the MS shall choose to attempt announced type 3 cell re- 
selection. 

Where the decision tree indicates that the MS should choose type 1 or type 2 cell re-selection and if the 
SwMI supports both of these types, the MS can choose either of them. In attempting type 1 cell re- 
selection, the SwMI may respond with a type 2 cell re-selection procedure causing the MS to select the 
MCCH on the neighbour cell instead of the SwMI directing the MS to the MCCH or to a traffic channel on 
the new cell. 

18.3.4.7.2 Undeclared cell re-selection < 

Undeclared cell re-selection shall be initiated by an MS if it is not currently involved in any circuit mode 
calls and one of the cell re-selection criteria described in subclause 18.3.4.7 is met causing a preferred 
neighbour cell to be selected. If cell re-selection is initiated as a result of a radio relinquishable, radio 
improvable or radio usable condition, a preferred neighbour cell shall have been identified by the MS-MLE. 
This preferred neighbour cell may or may not have been scanned by the MS-MLE before cell re-selection 
is initiated. If cell re-selection is initiated as a result of radio link failure, a preferred neighbour cell may not 
yet have been identified. 

Upon initiation of the undeclared cell re-selection procedure, the MS-MLE shall perform the following 
actions: 

a) issue MLE-BREAK indication, informing the higher layer 3 entities, CONP and CMCE, that the radio 
link to the current serving cell is unavailable for C-plane signalling; 

b) issue MLE-CLOSE indication, informing the higher layer 3 entity, SCLNP, that the radio link to the 
current serving cell is unavailable for C-plane signalling; 

c) if no preferred neighbour cell has been selected, initiate foreground scanning of neighbour cells to 
select a preferred neighbour cell; 

d) if a preferred neighbour cell has been selected and background scanning of the preferred cell has 
not been performed, initiate foreground scanning of the preferred cell to confirm the selection; 

e) issue TL-SELECT request via the TLC-SAP to cause the MAC to switch to the main carrier of the 
new cell; the MAC responds with TL-SELECT confirm once the new cell has been selected. 
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If the new cell is in a LA outside the current registration area and if registration is required on the new cell, 
MLE shall inform the MM of the LA, MNC and MCC of the new cell using MLE-LINK indication. MM shall 
then register on the new cell. 

MM shall indicate successful registration by issuing MLE-UPDATE request to MLE confirming the cell. If 
registration was successful or if no registration was necessary, MLE shall send MLE-REOPEN indication 
to the upper layer 3 entities, CMCE and CONP, to indicate that the radio link is once again available for C- 
plane signalling. MLE shall also send MLE-OPEN indication to the upper layer 3 entity, SCLNP, to indicate 
that the radio link is once again available for C-plane signalling. 

If the registration is unsuccessful, then MM shall inform MLE using MLE-UPDATE request. MLE may 
attempt to select another cell from the ranking list and reapply the undeclared cell re-selection procedure 
described above. If there are no more cells in the ranking list, which meet the cell re-selection criteria in 
subclause 18.3.4.7, then MLE shall inform MM by issuing MLE-ACTIVATE indication. MM shall then close 
the layer 3 SAPs by issuing MLE-CLOSE request which shall cause MLE to issue MLE-CLOSE indication 
to the higher layer 3 entities, CMCE, CONP and S-CLNP. 

18.3.4.7.3 Unannounced cell re-selection 

Unannounced cell re-selection shall be initiated by an MS if one of the cell re-selection criteria described in 
subclause 18.3.4.7 is met and unannounced cell re-selection is chosen according to the decision tree in 
figure 70. If cell re-selection is initiated as a result of a radio relinquishable, radio improvable or radio 
usable condition, a preferred neighbour cell shall have been identified by the MS-MLE. This preferred 
neighbour cell may or may not have been scanned by the MS-MLE before cell re-selection is initiated. If 
cell re-selection is initiated as a result of radio link failure, a preferred neighbour cell may not yet have 
been identified. 

Upon initiation of the unannounced cell re-selection procedure, the MS-MLE shall perform the following 
actions: 

a) issue MLE-BREAK indication, informing the higher layer 3 entities, CONP and CMCE, that the radio 
link to the current serving cell is unavailable for C-plane signalling; 

b) issue MLE-CLOSE indication, informing the higher layer 3 entity, SCLNP, that the radio link to the 
current serving cell is unavailable for C-plane signalling; 

c) locally disconnect any advanced links by issuing TL-RELEASE request via the TLA-SAP to layer 2; 

c) if no preferred neighbour cell has been selected, initiate foreground scanning of neighbour cells to 
select a preferred neighbour cell; 

e) if a preferred neighbour cell has been selected and background scanning of the preferred cell has 
not been performed, initiate foreground scanning of the preferred cell to confirm the selection; 

f) issue TL-SELECT request via the TLC-SAP to cause the MAC to switch to the main carrier of the 
new cell; the MAC responds with TL-SELECT confirm once the new cell has been selected. 

If the new cell is in a LA outside the current registration area and registration is required on the new cell, 
MLE shall inform MM of the LA, MNC and MCC of the new cell using MLE-LINK indication. MM shall then 
register. 
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Figure 71: Unannounced cell re-selection procedure 

If the registration is unsuccessful, then MM shall inform MLE using MLE-UPDATE request. MLE may 
attempt to select another cell from the ranking list and re-apply the unannounced cell re-selection 
procedure described above. If there are no more cells in the ranking list, which meet the cell re-selection 
criteria in subclause 18.3.4.7, then MLE shall inform MM by issuing MLE-ACTIVATE indication. MM shall 
then close the layer 3 SAPs by issuing MLE-CLOSE request which shall cause MLE to issue MLE-CLOSE 
indication to the higher layer 3 entities, CMCE, CONP and SCLNP. The MS may then initiate initial cell 
selection to find a suitable cell but shall not attempt restoration of circuit mode calls if a suitable cell is 
found. 

MM shall indicate successful registration by issuing MLE-UPDATE request to MLE confirming the ceil. If 
registration was successful or if no registration was necessary, MLE shall send MLE-RESUME indication 
to the upper layer 3 entities, CMCE and CONP, to indicate that the radio link is once again available for 
C-plane signalling. MLE shall also send MLE-OPEN indication to SCLNP to indicate that the radio link is 
once again available for C-ptane signalling. 

CMCE may attempt to restore any circuit mode calls which were in existence before the cell change. 
CMCE shall restore a call by responding to the MLE-RESUME indication primitive with MLE-RESTORE 
request, containing a CMCE call restoration PDU. MLE shall send a U-RESTORE PDU, containing the 
CMCE call restoration SDU using the LLC acknowledged service. The U-RESTORE PDU shall contain 
each of the following elements only if the value on the new cell is different from that on the old cell: 



MCC; 
MNC; 
LA. 



NOTE 1 : The MCC, MNC and LA refer to the old cell. 
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If call restoration is successful, MLE shall receive a D-RESTORE ACK PDU from the SwMI which shall 
contain the CMCE downlink call restoration signalling PDU. Upon receipt of the D-RESTORE ACK PDU 
indicating successful cell re-selection, MLE shall issue MLE-RESTORE confirm to the CMCE. The MLE- 
RESTORE confirm primitive which is passed to CMCE shall contain the CMCE restoration signalling PDU. 

NOTE 2: CMCE may attempt to restore multiple circuit mode calls using the above restoration 
procedure for each call. Calls shall be restored one at a time with a call restoration 
signalling sequence for each one. 

NOTE 3: A successful call restoration, indicated by D-CALL RESTORE/D-RESTORE ACK 
should include a channel allocation in the MAC header if the restored call currently has 
a traffic channel allocation. 

If the D-RESTORE FAIL PDU is received instead, it shall indicate that call restoration was unsuccessful. 
MLE shall then issue MLE-REOPEN indication to the CMCE to indicate that the radio path is restored, but 
that the calls have not been restored. The D-RESTORE FAIL PDU shall not carry an SDU for any of the 
higher layer 3 entities. 

CONP and SCLNP may re-establish packet data communications by re-sending data packets which have 
not yet been successfully transferred to the SwMI. On receiving MLE-RESUME indication (MLE-OPEN 
indication), CONP (SCLNP) may re-transmit data packets using MLE-UNITDATA request. The MLE may 
then establish an advanced link with the SwMI by issuing TL-CONNECT request to layer 2 to continue the 
data transfer on the new cell. 

1 8.3.4.7.4 Announced cell re-selection - type 3 

Announced type 3 cell re-selection shall be initiated by an MS if one of the cell re-selection criteria 
described in subclause 18.3.4.7 is met and announced type 3 cell re-selection is chosen according to the 
decision tree in figure 70. If cell re-selection is initiated as a result of a radio relinquishable, radio 
improvable or radio usable condition, a preferred neighbour cell shall have been identified by the MS-MLE. 
This preferred neighbour cell may or may not have been scanned by the MS-MLE before cell re-selection 
is initiated. If cell re-selection is initiated as a result of radio link failure, announced type 3 cell re-selection 
shall not be attempted by the MS. 

Upon initiation of the announced type 3 cell re-selection procedure, the MS-MLE shall send a 
U-PREPARE PDU to the SwMI. The U-PREPARE PDU shall not contain the cell identifier element and the 
PDU shall not carry an SDU. 

NOTE 1 : The fact that the cell identifier element is not present in the PDU informs the SwMI that 
a preferred neighbour cell has not yet been selected and that the MS-MLE is 
attempting announced type 3 cell re-selection. 

MLE shall send the U-PREPARE PDU by issuing TL-DATA request to layer 2 with the primitive 
parameters set as follows: 

PDU priority shall be set to 6; 

stealing permission shall be set to "steal immediately"; 

the stealing repeats flag shall not be set. 

NOTE 2: By transmitting the U-PREPARE PDU, the MS informs the SwMI that it is about to 
change cell and that the SwMI should disconnect any advanced links for that MS. The 
SwMI should also recognise the effect of the cell change on any circuit mode calls that 
the MS is currently involved in. 

MLE shall start timer, T370, and shall await the response from the SwMI. The SwMI shall respond with 
D-NEW CELL with the channel command valid element set either to "Change channel immediately" or "No 
channel change". If set to "Change channel immediately", MLE shall reset T370 and initiate the cell 
change procedure described below. If set to "No channel change", MLE shall restart timer, T370, and wait 
for another D-NEW-CELL PDU from the SwMI. If, while waiting for D-NEW CELL from the SwMI, radio 
link failure occurs, the MS shall abandon the announcement signalling and initiate the cell change 
procedure immediately. 
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Figure 72: Announced type 3 cell re-selection procedure 

If timer, T370, expires, the MS shall immediately initiate the cell change procedure as described below. 

The SwMI shall not respond to U-PREPARE with D-PREPARE FAIL in the case where the MS-MLE has 
not indicated a preferred neighbour cell in the U-PREPARE PDU. Therefore D-PREPARE FAIL shall not 
be a valid response for announced type 3 cell re-selection. 

Upon initiation of the cell change procedure, the MS-MLE shall: 

a) issue MLE-BREAK indication, informing the higher layer 3 entities, CONP and CMCE, that the radio 
link to the current serving cell is unavailable for C-plane signalling; 

b) issue MLE-CLOSE indication, informing the higher layer 3 entity, SCLNP, that the radio link to the 
current serving cell is unavailable for C-plane signalling; 

c) locally disconnect any advanced links by issuing TL-RELEASE request via the TLA-SAP to layer 2; 

d) initiate foreground scanning of the preferred neighbour cell (which has been selected as a result of 
monitoring and ranking) to confirm selection; 

e) issue TL-SELECT request via the TLC-SAP to cause the MAC to switch to the main carrier of the 
new cell; the MAC responds with TL-SELECT confirm once the new cell has been selected. 
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NOTE 4; If the BS receives U-PREPARE from an MS transmitting in a circuit mode call, the BS 
may remove the transmit permission by sending D-TX CEASED to the other MS(s) in 
the cell. Alternatively, the BS may allow the MS changing cell to keep the transmit 
permission for a period of time or until it selects a new cell and restores the call on that 
cell. 

If the new cell is in a LA outside the current registration area and registration is required on the new cell, 
MLE shall inform MM of the LA, MNC and MCC of the new cell using MLE-LINK indication. MM shall then 
register. 

If the registration is unsuccessful, then MM shall inform MLE using MLE-UPDATE request. MLE may 
attempt to select another cell from the ranking list and re-apply the unannounced cell re-selection 
procedure described above. If there are no more cells in the ranking list, which meet the cell re-selection 
criteria in subclause 18.3.4.7, then MLE shall inform MM by issuing MLE-ACTIVATE indication. MM shall 
then close the layer 3 SAPs by issuing MLE-CLOSE request which shall cause MLE to issue MLE-CLOSE 
indication to the higher layer 3 entities, CMCE, CONP and SCLNP. The MS may then initiate initial cell 
selection to find a suitable cell. 

MM shall indicate successful registration by issuing MLE-UPDATE request to MLE confirming the cell. If 
registration was successful or if no registration was necessary, MLE shall send MLE-RESUME indication 
to the upper layer 3 entities, CMCE and CONP, to indicate that the radio link is once again available for 
C-plane signalling. MLE shall also send MLE-OPEN indication to SCLNP to indicate that the radio link is 
once again available for C-plane signalling. 

CMCE may attempt to restore any circuit mode calls which were in existence before the cell change. 
CMCE shall restore calls by responding to the MLE-RESUME indication primitive with MLE-RESTORE 
request, containing a CMCE call restoration PDU. MLE shall send a U-RESTORE PDU, containing the 
CMCE call restoration SDU using the LLC acknowledged service. The U-RESTORE PDU shall contain 
each of the following elements only if the value on the new cell is different from that on the old cell: 

MNC; 
MCC; 
LA. 

If call restoration is successful, MLE shall receive a D-RESTORE ACK PDU from the SwMI which shall 
contain the CMCE downlink call restoration signalling PDU. Upon receipt of the D-RESTORE ACK PDU 
indicating successful cell re-selection, MLE shall issue MLE-RESTORE confirm to the CMCE. The 
MLE-RESTORE confirm primitive which is passed to CMCE shall contain the CMCE restoration signalling 
PDU. 

NOTE 5: CMCE may attempt to restore multiple circuit mode calls using the above restoration 
procedure for each call. Calls are restored one at a time with a call restoration 
signalling sequence for each one. 

If the D-RESTORE FAIL PDU is received instead, it shall indicate that call restoration was unsuccessful. 
MLE shall then issue MLE-REOPEN indication to the CMCE to indicate that the radio path is restored, but 
that the call has not been restored. The D-RESTORE FAIL PDU shall not carry an SDU for any of the 
higher layer 3 entities. 

CONP and SCLNP may re-establish packet data communications by re-sending data packets which have 
not yet been successfully transferred to the SwMI. On receiving MLE-RESUME indication (MLE-OPEN 
indication), CONP (SCLNP) may re-transmit data packets using MLE-UNITDATA request. The MLE may 
then establish an advanced link with the SwMI by issuing TL-CONNECT request to layer 2 to continue the 
data transfer on the new cell. 

1 8.3.4.7.5 Announced cell re-selection - type 2 

Announced type 2 cell re-selection shall be initiated by an MS if one of the cell re-selection criteria 
described in subclause 18.3.4.7 is met and announced type 2 cell re-selection is chosen according to the 
decision tree in figure 70 and announced type 2 cell re-selection is supported for the preferred neighbour 
cell as indicated in the D-NWRK-BROADCAST PDU. A preferred neighbour cell shall have been identified 
by the MS-MLE and shall have been scanned prior to initiating the cell re-selection procedure. If cell re- 
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Figure 73: Announced type 2 cell re-selection procedure 

Upon initiation of the announced cell re-selection type 2 procedure, the MS-MLE shall send a 
U-PREPARE PDU to the SwMI. The U-PREPARE PDU shall not contain an SDU. The U-PREPARE PDU 
shall contain the cell identifier element which shall uniquely identify a cell as defined by the 
D-NWRK-BROADCAST. 



NOTE 1: The fact that that the U-PREPARE PDU contains details which identify a preferred 
neighbour cell informs the SwMI that the MS is attempting announced type 1 or 
announced type 2 cell re-selection. If the MS is already registered in the preferred 
neighbour cell, the SwMI may direct the MS to a channel on the new cell using a MAC 
channel allocation thus performing announced type 1 cell re-selection. 

MLE shall send the U-PREPARE PDU by issuing TL-DATA request to layer 2 with the primitive 
parameters set as follows: 

PDU priority shall be set to 6; 

stealing permission shall be set to "steal immediately*'; 

the stealing repeats flag shall not be set. 

NOTE 2: By transmitting the U-PREPARE PDU, the MS informs the SwMI that it is about to 
change cell and that the SwMI should disconnect any advanced links for that MS. The 
SwMI should also recognise the effect of the cell change on any circuit mode calls that 
the MS is currently involved in. 

MLE shall start timer, T370, and shall await the response from the SwMI. The SwMI shall respond with 
D-NEW CELL with the channel command valid element set either to "Change channel immediately", "No 
channel change" or "Follow MAC channel change". 

If set to "Change channel immediately", MLE shall reset T370 and initiate the cell change procedure 
described below. 
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If set to "No channel change", MLE shall restart timer, T370, and wait for another D-NEW-CELL PDU from 
the SwMI. 

The SwMI shall only respond with "Follow MAC channel change" if the MS is already registered in the new 
cell. In this case, the MS shall then follow the cell change procedures for announced type 1 cell 
re-selection. 

If while waiting for D-NEW CELL from the SwMI, radio link failure occurs or timer T370 expires, the MS 
shall abandon the announcement signalling and shall immediately initiate the cell change procedure 
described below. 

If the MS-MLE receives a D-PREPARE FAIL PDU from the SwMI, the MS-MLE may attempt announced 
cell re-selection to another neighbour cell in the ranking list which meets one of the cell re-selection 
criteria described in subclause 18.3.4.7. If no other cells in the ranking list meet one of the cell re-selection 
criteria or if announced cell re-selection fails for all available cells, MLE may continue to use the current 
serving cell. 

Upon initiation of the cell change procedure, the MS-MLE shall: 

a) issue MLE-BREAK indication, informing the higher layer 3 entities, CONP and CMCE, that the radio 
link to the current serving cell is unavailable for C-plane signalling; 

b) issue MLE-CLOSE indication to SCLNP to indicate that the radio link to the current serving cell is 
unavailable for C-plane signalling; 

c) locally disconnect any advanced links by issuing TL-RELEASE request via the TLA-SAP to layer 2; 

d) issue TL-SELECT request via the TLC-SAP to cause the MAC to switch to the main carrier of the 
new cell; the MAC responds with TL-SELECT confirm once the new cell has been selected. 

If the new cell is in a LA outside the current registration area and registration is required on the new cell, 
MLE shall inform MM of the LA, MNC and MCC of the new cell using MLE-LINK indication. MM shall then 
register. 

If the registration is unsuccessful, then MM shall inform MLE using MLE-UPDATE request. MLE may 
attempt to select another cell from the ranking list and reapply the unannounced cell re-selection 
procedure described above. If there are no more cells in the ranking list, which meet the cell re-selection 
criteria in subclause 18.3.4.7, then MLE shall inform MM by issuing MLE-ACTIVATE indication. MM shall 
then close the layer 3 SAPs by issuing MLE-CLOSE request which shall cause MLE to issue MLE-CLOSE 
indication to the higher layer 3 entities, CMCE, CONP and S-CLNP. The MS may then initiate initial cell 
selection to find a suitable cell. 

MM shall indicate successful registration by issuing MLE-UPDATE request to MLE confirming the cell. If 
registration was successful or if no registration was necessary, MLE shall send MLE-RESUME indication 
to the upper layer 3 entities, CMCE and CONP, to indicate that the radio link is once again available for 
C-plane signalling. MLE shall send MLE-OPEN indication to SCLNP to indicate that the radio link is once 
again available for C-plane signalling. 

CMCE may attempt to restore any circuit mode calls which were in existence before the cell change. 
CMCE shall restore calls by responding to the MLE-RESUME indication primitive with MLE-RESTORE 
request, containing a CMCE call restoration PDU. MLE shall send a U-RESTORE PDU, containing the 
CMCE call restoration SDU using the LLC acknowledged service. The U-RESTORE PDU shall contain 
each of the following elements only if the value on the new cell is different from that on the old cell: 

MCC; 
MNC; 
LA. 

If call restoration is successful, MLE shall receive a D-RESTORE ACK PDU from the SwMI which shall 
contain the CMCE downlink call restoration signalling PDU. Upon receipt of the D-RESTORE ACK PDU 
indicating successful cell re-selection, MLE shall issue MLE-RESTORE confirm to CMCE. The MLE- 
RESTORE confirm primitive which is passed to CMCE shall contain the CMCE restoration signalling PDU. 
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NOTE 3: CMCE may attempt to restore multiple circuit mode calls using the above restoration 
procedure for each call. Calls are restored one at a time with a call restoration 
signalling sequence for each one. 

If the D-RESTORE FAIL PDU is received instead, it shall indicate that call restoration was unsuccessful. 
MLE shall then issue MLE-REOPEN indication to the CMCE to indicate that the radio path is restored, but 
that the call has not been restored. The D-RESTORE FAIL PDU shall not carry an SDU for any of the 
higher layer 3 entities. 

CONP and SCLNP may re-establish packet data communications by re-sending data packets which have 
not yet been successfully transferred to the SwMI. On receiving MLE-RESUME indication (MLE-OPEN 
indication), CONP (SCLNP) may re-transmit data packets using MLE-UNITDATA request. The MLE may 
then establish an advanced link with the SwMI by issuing TL-CONNECT request to layer 2 to continue the 
data transfer on the new cell. 

18.3.4.7.6 Announced cell re-selection - type 1 

Announced type 1 cell re-selection shall be initiated by an MS if one of the cell re-selection criteria 
described in subclause 1 8.3.4.7 is met and announced type 1 cell re-selection is chosen according to the 
decision tree in figure 70 and announced type 1 cell re-selection is supported for the preferred neighbour 
cell as indicated in the D-NWRK-BROADCAST PDU. A preferred neighbour cell shall have been identified 
by the MS-MLE and shall have been scanned prior to initiating the cell re-selection procedure. If cell 
re-selection is initiated as a result of radio link failure or if the preferred neighbour cell has not yet been 
scanned, announced type 1 cell re-selection shall not be attempted by the MS. 

Upon initiation of the announced type 1 cell re-selection procedure, the MS shall determine if registration 
is required in the new cell. Registration shall be required if the following conditions are simultaneously 
satisfied: 

the preferred neighbour cell is in a LA which is outside the current registered area of the MS; 

registration is required in the new cell as indicated in the BS service details element which is either 
received as part of the neighbour cell information element in the D-NWRK-BROADCAST PDU or 
obtained directly by scanning the neighbour cell BNCH. 

If registration is not required on the new cell, the MS-MLE shall initiate the procedure described in 
subclause 18.3.4.6.5 for announced type 2 cell re-selection. 

NOTE 1 : For the case where an MS is already registered on a preferred neighbour cell, type 1 
and type 2 announced cell re-selection procedures are initiated by the MS using 
identical procedures. The MS-MLE sends the U-PREPARE PDU to the SwMI. The 
SwMI may then decide whether to direct the MS to a TCH or the MCCH on the new 
cell using a MAC channel allocation (type 1) or simply to allow the MS to select the 
new cell (type 2). 
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Figure 74: Announced type 1 cell re-selection procedure 

if registration is required, MLE shall issue MLE-LINK indication to MM which shall have the following 
parameters: 

MCC of the preferred neighbour cell; 
MNC of the preferred neighbour cell; 
LA of the preferred neighbour cell; 

registration type shall be set to "forward" to indicate that forward registration (i.e. registration in a 
cell other than the current serving cell) is required. 

The MM shall then initiate forward registration by issuing MLE-PREPARE request which shall have 
contain a registration SDU as a parameter. MLE shall then send a U-PREPARE PDU to the SwMI which 
shall contain the MM registration SDU. The U-PREPARE PDU shall contain the cell identifier element 
which shall uniquely identify a cell as defined by the D-NWRK-BROADCAST PDU. 

NOTE 2: The fact that that the U-PREPARE PDU contains details which identify a preferred 
neighbour cell informs the SwMI that the MS is attempting announced type 2 or 
announced type 1 cell re-selection. If the MS is already registered on the preferred 
neighbour cell, the SwMI may direct the MS to the MCCH or to the TCH on the new 
cell using a MAC channel allocation. If the PDU carries a registration SDU, this informs 
the SwMI that the MS is requesting a type 1 cell re-selection. However, even in this 
case, the SwMI may decide to direct the MS to a channel on the new cell using a MAC 
channel allocation (type 1 re-selection) or simply indicate the MS is free to select the 
new cell (type 2 re-selection) and switch to the MCCH of that cell. The SwMI therefore 
ultimately controls whether type 1 or type 2 cell re-selection is applied. 



NOTE 3: By transmitting the U-PREPARE PDU, the MS informs the SwMI that it is about to 
change cell and that the SwMI should disconnect any advanced links for that MS. The 
SwMI should also recognise the effect of the cell change on any circuit mode calls that 
the MS is currently involved in. 

If cell re-selection is successful, the SwMI may respond to the combined registration and cell re-selection 
preparation in one of two ways as follows: 

1) Successful type 1 cell re-selection: 

the SwMI shall respond with a D-NEW CELL PDU which shall contain an MM SDU accepting 
registration on the new cell. The MM SDU shall be passed to MM using MLE-PREPARE 
confirm. MLE-UPDATE request shall then indicate successful registration to MLE; 

upon reception of D-NEW CELL, MS-MLE shall initiate the cell change procedure as follows: 

a) issue MLE-BREAK indication, informing the higher layer 3 entity, CONP, that the radio 
link to the current sewing cell is unavailable for C-plane signalling; 
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b) issue MLE-CLOSE indication, informing the higher layer 3 entity, SCLNP that the radio 
link to the current serving cell is unavailable for C-plane signalling; 

c) locally disconnect any advanced links by issuing TL-RELEASE request via the TLA- 
SAP to layer 2; 

the "Channel command valid" element in the D-NEW-CELL PDU shall be set to "Follow MAC 
channel allocation" to indicate that a TCH has been allocated on the new cell to continue the 
circuit mode call or that the MS has to switch to the MCCH of the new cell to continue the 
call. The MAC shall automatically follow the channel allocation in the MAC header and the 
MS shall continue the call on the new cell assuming the same U-plane/C-plane mode and 
transmit permission as it had on the old cell; 

the MAC indicates the channel change using TL-SELECT indication to which the MLE shall 
respond with TL-SELECT response containing a parameter to inform to the MAC of the main 
carrier frequency on the new cell. On receiving TL-SELECT indication indicating that the 
channel change has been completed by the MAC, the MLE shall send MLE-RESUME 
indication to CONP and MLE-OPEN indication to SCLNP to indicate that the radio link is once 
again available for C-plane signalling. 

NOTE 4: In this case, there shall be no need for call restoration signalling on the new cell. 
2) Successful type 2 cell re-selection: 

the SwMI may accept registration on the new cell but not direct the MS to a channel on the 
new cell rather the MS switches autonomously to the MCCH of the new cell. In this case the 
SwMI shall respond with a D-NEW CELL PDU which shall contain an MM SDU accepting 
registration on the new cell. The MM SDU shall be passed to MM using MLE-PREPARE 
confirm. MLE-UPDATE request shall indicate successful registration to MLE; 

the Channel command valid element shall be set to "Change channel immediately" which 
shall cause the MS to initiate the cell change procedure as follows: 

a) issue MLE-BREAK indication, informing the higher layer 3 entities, CONP and CMCE, 
that the radio link to the current serving cell is unavailable for C-plane signalling; 

b) issue MLE-CLOSE indication to inform the higher layer 3 entity, SCLNP that the radio 
link to the current serving cell is unavailable for C-plane signalling; 

c) locally disconnect any advanced links by issuing TL-RELEASE request via the 
TLA-SAP to layer 2; 

d) issue TL-SELECT request via the TLC-SAP to cause the MAC to switch to the main 
carrier of the new cell; the MAC responds with TL-SELECT confirm once the new cell 
has been selected; 

e) issue MLE-RESUME indication to the upper layer 3 entities, CMCE and CONP to 
indicate that the radio link is once again available for C-plane signalling; 

0 issue MLE-OPEN indication to the upper layer 3 entity, SCLNP to indicate that the 
radio link is once again available for C-plane signalling. 

CMCE may then attempt to restore circuit mode calls by applying the same call restoration procedure as is 
used for announced type 2 cell re-selection. 

If cell re-selection is not successful, the SwMI shall respond to the MS with a D-PREPARE FAIL PDU 
which shall carry an MM PDU rejecting registration on the new cell. The MM SDU shall be passed to MM 
using MLE-PREPARE confirm. MLE-UPDATE request shall then inform MLE that the cell re-selection was 
not successful. 
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The MS may attempt cell re-selection to another neighbour cell in the ranking list which meets one of the 
re-selection criteria described in subclause 18.3.4.7. If no other cells in the ranking list meet one of the cell 
re-selection criteria or if announced cell re-selection fails for all available cells, MLE may continue to use 
the current serving cell. 

All other combinations of D-NEW CELL/D-PREPARE FAIL and MM registration PDUs shall not be sent by 
the SwMI during announced type 1 cell re-selection. 

CONP and SCLNP may re-establish packet data communications on a new cell by re-sending data 
packets which have not yet been successfully transferred to the SwMI. On receiving MLE-RESUME 
indication (MLE-OPEN indication), CONP (SCLNP) may re-transmit data packets using MLE-UNITDATA 
request. The MLE may then establish an advanced link with the SwMI by issuing TL-CONNECT request to 
layer 2 to continue the data transfer on the new cell. 

1 8.3.5 Data transfer sub-entity 

The services and primitives offered by the MLE are described in clause 17. 
18.3.5.1 Address handling 

The MLE manages all of the subscriber addresses (i.e. ITSls and GTSIs) plus the management identity 
(i.e. TMI). These addresses and identities are described in ETS 300 392-1 [11], clause 7. 

System subscriber Identities which are received or attached and detached by the MM entity should be 
transferred to MLE in an MLE-IDENTITIES request primitive. After being recorded locally and any lists 
amended, the list of currently valid short subscriber and management identities shall be transferred to the 
lower layers via the TLC-SAP in a TL-CONFIGURE request primitive as described in 
subclause 18.3.5.1.2. 

Temporary group system subscriber identities which are received by the SS sub-entity within the CMCE, 
or which are attached by the MM protocol, shall be transferred to MLE in an MLE-IDENTITIES request 
primitive. After being recorded locally and any lists amended, the list of currently valid short subscriber and 
management identities shall be transferred to the lower layers via the TLC-SAP in a TL-CONFIGURE 
request primitive as described in subclause 18.3.5.1.2. The MLE shall record locally which identities are 
temporary. The receipt of an MLE-IDENTITIES request primitive from the CMCE-SAP with a new list of 
identities specified shall delete all previous temporary identities and replace them with the newly received 
temporary identities. The receipt of an MLE-IDENTITIES request primitive from the CMCE-SAP with no 
identities specified shall delete all temporary identities. The updated lists shall be transferred to the lower 
layers via the TLC-SAP in a TL-CONFIGURE request primitive as described in subclause 18.3.5.1.2. 

1 8.3.5.1 .1 Link addressing 

The MLE defines the MAIN ADDRESS and the ADDRESS TYPE parameters in all TL-CONNECT, 
TL-DATA, TL-DISCONNECT and TL-UNITDATA primitives issued to layer 2. The MAIN ADDRESS shall 
comprise of a valid SSI. 

For messages containing higher layer information, the MLE sets the MAIN ADDRESS SSI parameter to a 
valid SSI, as defined in ETS 300 392-1 [11], clause 7. During migration, exchanged addresses shall be 
used, using the exchanged addresses issued by the MM in the MLE-IDENTITIES request primitive. 

if there is no valid SSI the MLE shall use an un-exchanged SSI (USSI) as defined in ETS 300 392-1 [11], 
clause 7. An un-exchanged SSI may only be used for MM messages. 

For messages from the MLE management entity, the MLE shall always add the SMI. The SMI is defined in 
ETS 300 392-1 [11], clause 7. 

The MLE shall remove the MAIN ADDRESS and the ADDRESS TYPE parameters from all primitives 
received from layer 2. These parameters can be used for upward routing. 
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1 8.3.5.1 .2 Link addresses to be placed in layer 2 

In order to be able to filter, in layer 2, those messages received by the MS that are not applicable, layer 2 
requires to be informed of all addresses that are valid for the MS. The MLE shall inform layer 2 by means 
of a TL-CONFIGURE request the short subscriber and management identities that are valid for the MS. 

In the event that a SSI ceases to be valid, then the MLE shall inform layer 2 by means of a 
TL-CONFIGURE request via the TLC-SAP. 

1 8.3.5.1 .3 Layer 2 end point identifier 

The MLE receives the layer 2 endpoint identifier in all primitives exchanged with the layer 2. Endpoint 
identifier is assumed to be a local layer-to-layer matter, and is not defined in this ETS. 

Endpoint identifiers are required to distinguish between multiple LLC links for a given MS to SwMI MLE 
pairing. This includes both multiple values of SSI and multiple cell attachments (for a given value of SSI). 

1 8.3.5.1 .4 Subscriber class 

The MM informs the MLE of the MS subscriber class membership for a particular ITSI using an 
MLE-INFO request primitive. The MLE shall then use this value as the parameter attached to 
TL-UNITDATA request, TL-DATA request, TL-CONNECT request and TL-DISCONNECT request for all 
subsequent outgoing PDUs. The subscriber class is a bit mapped field which shall indicate which 
subscriber classes the MS is a member of. The values are specified in subclause 18.5. The subscriber 
class parameter may be allocated at subscription or registration. If the MS does not have a subscriber 
class from registration or subscription, the MS shall assume membership of all subscriber classes. 

Where the received network broadcast information indicates that the subscriber class associated with the 
ITSI is not valid on a cell the MLE shall filter service requests until the subscriber class becomes valid, or 
a new cell is selected where the subscriber class is valid. In addition, the MLE shall only allow the higher 
layers to transfer PDUs which relate to existing circuit mode calls. The MLE shall disallow PDUs relating to 
a new calls, unless they have a message priority of 7, indicating an emergency call. If an MS subscriber 
class is not supported by the current serving cell, the MS shall only be allowed to register on that cell, 
initiate emergency calls or signalling, and receive incoming calls/signalling on that cell. 

18.3.5.2 MLE connection handling 

An MLE connection is the logical association of the MLE peer entities in the MS/LS and the SwMI. The 
association is made by the mobile when it acquires a radio channel and camps on a cell. No explicit 
signalling is required in order to establish the connection. 

1 8.3.5.2.1 Data transfer states 

The following states shall exist in the data transfer entity. 

NOTE: In the state machine the states themselves are provided for information, but 
conformance to the signalling specified for the output of the state machine is a 
requirement. 

a) Closed: 

the data transfer sub-entity shall enter state Closed after initial start up. This state shall also 
be entered after an MLE-CLOSE request has been received from the MM entity indicating 
that there shall be no access to communication resources allowed. 

b) Idle: 

the data transfer sub-entity shall enter the state Idle if it has received an MLE-OPEN request 
and has not subsequently received an MLE-CLOSE request or MLE-BREAK indication. 
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c) Busy: 

the data transfer sub-entity shall enter the busy state upon receiving an MLE-BUSY request 
from MM, CONP or SCLNP. Whilst in this state it shall count the number of MLE-BUSY 
request messages received, and shall only leave this state once the corresponding number 
of MLE-IDLE request messages have been received; 

in the busy state, the MLE shall reject any group addressed channel change commands 
received from the MAC in TL-SELECT indication. MM can use MLE-BUSY request to prevent 
the MS from following a group-addressed channel change while individual signalling 
exchange with the SwMI is in progress. 

d) Broken: 

the data transfer sub-entity enters this state upon receipt of an MLE-BREAK indication from 
the attachment management sub-entity and indicates that the connection is temporarily 
broken. Upon receiving an MLE-RESUME indication or an MLE-REOPEN indication the data 
transfer sub-entity shall return to the idle state. 

18.3.5.3 Message routing and selection of LLC services 

The service routing possibilities are shown in table 219. 



Table 219: Service routing 



Service user 


Layer 2 service used 


Uplink 


Downlink 


SAP 


CONP 


point-to-point acknowledged at layer 2 


ack 


ack 


TLA 


SCLNP 


point-to-point acknowledged at layer 2 


ack 


ack 


TLA 




point-to-Doint unacknowledaed at laver 2 


unack 


unack 


TLA 




point-to-multipoint unacknowledged at layer 2 


not applicable 


unack 


TLA 


MM 


point-to-point acknowledged at layer 2 


ack 


ack 


TLA 




point-to-point unacknowledged at laver 2 


unack 


unack 


TLA 


CMCE 


point-to-point acknowledged at laver 2 


ack 


ack 


TLA 




Doint-to-multipoint unacknowledged at layer 2 


not applicable 


unack 


TLA 


SYSTEM 
BROADCAST 


point-to-multipoint unacknowledged at layer 2 
(system information PDU) 


not applicable 


unack 


TLB 


LOCAL 

MANAGEMENT 


layer-to-layer exchange only 


not applicable 


not applicable 


TLC 



1 8.3.5.3.1 Selection of LLC services via TLA-SAP 



Two types of data transfer are available at the layer 2 TLA-SAP: 

acknowledged PDU transfer; and 

unacknowledged PDU transfer. 

The acknowledged service provides bi-directional data transfer, the unacknowledged service is 
unidirectional. 

The required service shall be interpreted from the information contained in the primitives from the higher 
entities according to the procedures specified below. 

The PDU priority, stealing permission and stealing repeats flag parameters shall be set by the sending 
higher layer 3 entity and simply passed on to layer 2 by the MLE. In addition, for TL-CONNECT and 
TL-DISCONNECT primitives which are issued by the MLE, the stealing permission parameter shall be set 
to "stealing not required" and the stealing repeats flag shall not be set. The PDU priority shall be equal to 3 
for TL-CONNECT and 6 for TL-DISCONNECT. 
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Where the subscriber class associated with the ITSI is not valid at the serving cell, the data transfer 
sub-entity shall only allow the following outgoing messages: 

messages associated with ongoing calls/connections; 

responses to incoming call set-up requests; and 

outgoing "emergency'' calls. 

Outgoing "emergency" calls are identified as those calls having a PDU priority level of 7. All other requests 
shall be rejected with an MLE-REPORT indication to the originating sub-entity or higher layer entity. 

a) Outgoing messages from CONP and SCLNP 

The data transfer sub-entity shall reject service requests from CONP and SCLNP when in state closed. 
When in the broken state, messages shall not be passed by the MLE. 

All outgoing messages shall be subject to the following handshake procedure with the LLC. 

Upon receipt of the TL-CONNECT, -DISCONNECT, -DATA, or -UNITDATA request primitive the LLC 
shall immediately acknowledge this with a TL-REPORT indication containing the handle. The handle 
should be retained locally and used for routing subsequent REPORT primitives. 

Where the outgoing message has resulted in the MLE requesting an unacknowledged service from the 
LLC, the handle remains valid until a further TL-REPORT indication is received indicating that the PDU 
has been transmitted, or, a TL-CANCEL request is issued when the handle is deleted. 

Where the outgoing message has resulted in the MLE requesting an acknowledged service from the LLC, 
the handle remains valid until a TL-DATA confirm is received indicating that the PDU has been 
successfully transmitted, or, a TL-CANCEL request is issued when the handle is deleted. TL-CANCEL 
requests may be issued until the receipt of the second TL-REPORT indication, even though the handle 
remains valid in the latter case. 

On receipt of a TL-DATA confirm, the MLE shall issue an MLE-REPORT indication indicating successful 
transmission of the PDU transmitted as a result of the previous TL-DATA request on that endpoint 
identifier. If the TL-DATA confirm contains an SDU, this shall then be passed to the higher layers using 
MLE-UNITDATA indication. 

On receipt of an MLE-UNITDATA request, the data transfer sub-entity shall append an MLE PDU header 
indicating the originating SAP using the protocol discriminator field. The protocol discriminator values are 
defined in subclause 18.5. The data transfer sub-entity shall determine the length of the PDU and pass 
the information to the LLC as a primitive parameter. 

If the L2 service request parameter has the value "acknowledged request" then the MLE UNITDATA PDU 
shall be transferred to the LLC in a TL-DATA request primitive. 

If the L2 service request parameter has the value "acknowledged response" then the MLE UNITDATA 
PDU shall be transferred to the LLC in a TL-DATA response primitive. 

If the L2 service request parameter has the value "unacknowledged" then the MLE UNITDATA PDU shall 
be transferred to the LLC in a TL-UNITDATA-request primitive. 

NOTE1: Generally the packet data services CONP and SCLNP only use acknowledged 
request. 

CONP and SCLNP may use either advanced link or basic link although it is recommended that they use 
advanced link to ensure reliable transmission of long packets (i.e. longer than about 3 TDMA slots worth 
of data). The MS shall only attempt to set-up an advanced link if it is supported by the SwMI on this cell as 
indicated in the BS service details element broadcast as part of the D-MLE SYSINFO PDU. The quality of 
service parameters passed down by the CONP or SCLNP using MLE-UNITDATA request may be used by 
the MS in negotiating the advanced link service during set-up. How the CONP and SCLNP QoS 
parameters map onto the advanced link quality of service selection in the AL-SETUP PDU is not defined 



Page 291 

ETS 300 392-2: March 1996 

in this ETS. Similarly, whether or not the optional FCS is selected in basic link transfer is not defined in 
this ETS. 

Where the basic link is selected the SDU shall be sent to the TLA SAP in a TL-DATA request primitive 
unless an unacknowledged data transfer is specifically requested, in which case the SDU shall be sent in 
a TL-UNITDATA request primitive. 

Where the advanced link is selected the MS MLE shall issue a TL-CONNECT request primitive to the TLA 
SAP. Upon receipt of the TL-CONNECT confirm primitive from the TLA SAP, the MS MLE shall send the 
SDU in a TL-DATA request primitive. 

Once the TL-DATA confirm has been received indicating that the SDU has been successfully transmitted, 
and no further MLE-UNITDATA requests have been received from CONP or SCLNP, and the 
CONP/SCLNP has no more data to send the MS-MLE may issue a TL-DISCONNECT request primitive to 
the TLA SAP. The MS-MLE shall not establish any more advanced links after the TL-DISCONNECT 
request has been sent, until either a TL-DISCONNECT confirm is received, or a TL-REPORT indication is 
received indicating a failure. When either of these primitives is returned, any local MLE reference to the 
advanced link should be deleted. 

On receipt of an MLE-RESET request primitive from the CONP SAP, the data transfer sub-entity shall 
issue a TL-CONNECT request primitive to the TLA-SAP. Upon receipt of the TL-CONNECT confirm, the 
data transfer sub-entity shall issue an MLE-RESET confirm to the appropriate SAP. 

On receipt of an MLE-RESET response primitive from the CONP SAP, the data transfer sub-entity shall 
issue a TL-CONNECT response primitive to the TLA-SAP. 

On receipt of an MLE-CANCEL request primitive either from the CONP SAP, or, from the SCLNP SAP, 
the data transfer sub-entity shall issue a TL-CANCEL request primitive to the TLA-SAP. Once the 
TL-CANCEL request is issued any references to the handle in the MLE shall be deleted. 

b) Incoming messages to CONP and SCLNP 

If the data transfer process is in state busy then it shall check each primitive received from the LLC to see 
if it contains a GSSI addressed PDU with a related channel change request. If this is the case then that 
PDU shall be discarded, and the channel change shall not be obeyed. 

On receipt of a TL-CONNECT indication, the data transfer sub-entity shall establish if the TL-CONNECT 
indication refers to an established advanced link. This can be established by using the endpoint identifier. 
If the TL-CONNECT indication refers to an existing connection, the data transfer sub-entity shall issue an 
MLE-RESET indication to the appropriate SAP and issue a TL-CONNECT response primitive to the 
TLA-SAP. If the TL-CONNECT indication does not refer to an existing connection, the data transfer 
sub-entity shall allocate a new connection ID and issue a TL-CONNECT response primitive to the 
TLA-SAP. 

The receipt of the TL-CONNECT confirm is dealt with in subclause 18.3.5.3.1 a) as part of the advanced 
link establishment and maintenance. 

On receipt of a TL-DISCONNECT indication, the data transfer sub-entity shall establish if the 
TL-DISCONNECT indication refers to an established advanced link. This can be established by using the 
endpoint identifier. If it does refer to an established advanced link, any local reference to that advanced 
link shall be deleted. 

The receipt of the TL-DISCONNECT confirm is dealt with in subclause 18.3.5.3.1 a) as part of the 
advanced link establishment and maintenance. 

On receipt of a TL-UNITDATA indication, the data transfer sub-entity shall remove and analyse the MLE 
PDU header and address. The PDU header indicates the destination SAP. The data contained in the 
TL-UNITDATA indication shall then be routed to the correct SAP or sub-entity as an MLE-UNITDATA 
indication primitive. Network broadcast D-NWRK-BROADCAST messages shall be routed by the data 
transfer sub-entity to the network broadcast sub-entity. All other MLE protocol PDUs shall be handled by 
the attachment management sub-entity. 
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On receipt of a TL-DATA indication, the data transfer sub-entity shall remove and analyse the MLE PDU 
header. The PDU header indicates the destination SAP. The data contained in the TL-DATA indication 
shall then be routed to the correct SAP or sub-entity as an MLE-UNITDATA indication primitive. 

On receipt of a TL-DATA confirm, the MLE shall issue an MLE-REPORT indication primitive to indicate 
successful transmission of the PDU transmitted as a result of the previous TL-DATA request on that 
endpoint identifier. The data transfer sub-entity shall then remove and analyse the MLE PDU header. The 
PDU header indicates the destination SAP. The data contained in the TL-DATA confirm shall then be 
routed to the correct SAP or sub-entity as an MLE primitive, as determined by the MLE PDU header. 
MLE-UNITDATA PDUs are routed to the appropriate SAP in MLE-UNITDATA indication primitives. 

c) Outgoing messages from MM and CMCE 

All outgoing messages shall be subject to the following handshake procedure with the LLC. 

Upon receipt of the TL-DATA request primitive the LLC shall immediately acknowledge this with a 
TL-REPORT indication containing the handle. The handle should be retained locally and used for routing 
subsequent REPORT primitives. The handle remains valid until a TL-DATA confirm is received indicating 
that the PDU has been (successfully) transmitted, or, a TL-CANCEL request is issued when the handle is 
deleted. TL-CANCEL requests may be issued until the receipt of the second TL-REPORT indication. 

On receipt of TL-REPORT indication indicating successful transmission, the MLE shall issue 
MLE-REPORT indication to the SAP which sent the original TL-DATA request primitive to inform the 
higher layer 3 entity that the PDU has been successfully transmitted by layer 2. 

On receipt of an MLE-UNITDATA request, the data transfer sub-entity shall append an MLE PDU header 
indicating the originating SAP using the protocol discriminator field. The PDU header values are defined in 
subclause 18.4.2. The data transfer sub-entity shall determine the length of the PDU and pass that 
information to the LLC as a primitive parameter. 

The underlying service selected shall be the basic link and determined according to the L2 service 
parameter in the MLE-UNITDATA request primitive. 

If the L2 service request parameter has the value "acknowledged request" then the MLE UNITDATA PDU 
shall be transferred to the LLC in a TL-DATA request primitive. 

If the L2 service request parameter has the value "acknowledged response" then the MLE UNITDATA 
PDU shall be transferred to the LLC in a TL-DATA response primitive. 

NOTE 2: The CMCE and MM in the MS do not use the unacknowledged layer 2 service for 
uplink data transfer. 

On receipt of an MLE-CANCEL request primitive from the CMCE or MM SAP, the data transfer sub-entity 
shall issue a TL-CANCEL request primitive to the TLA-SAP. Once the TL-CANCEL request has been 
issued any references to the handle in the MLE shall be deleted. 

The basic link shall be used for all MM signalling and CMCE call related signalling. The FCS flag may be 
set to indicate the use of the optional FCS for basic link transfer. Whether or not the optional FCS is 
selected for basic link transfer is not defined in this ETS. 

The advanced link which is described for CONP and SCLNP data transfer may also be used for transfer 
of long SDUs. This may be required for the short data service which can send up to 2 047 bits of data or 
for transfer of call unrelated SS information. 

d) Incoming messages to MM and CMCE 

If the data transfer process is in state busy then it shall check each primitive received from the LLC to see 
if it contains a GSSI addressed PDU with a related channel change request. If this is the case then that 
PDU shall be discarded, and the channel change shall not be obeyed. 

On receipt of a TL-UNITDATA indication, the data transfer sub-entity shall remove and analyse the MLE 
PDU header and address. The PDU header indicates the destination SAP. The address may indicate that 
this is a network broadcast message. The data contained in the TL-UNITDATA indication shall then be 
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routed to the correct SAP or sub-entity as an MLE-UNITDATA indication primitive. Network broadcast 
D-NWRK-BROADCAST messages shall be routed by the data transfer sub-entity to the network 
broadcast sub-entity. Late entry information from the D-MLE-SYSINFO PDU shall be routed to the CMCE 
SAP. 

On receipt of a TL-DATA indication, the data transfer sub-entity shall remove and analyse the MLE PDU 
header. The PDU header indicates the destination SAP. The data contained in the TL-DATA indication 
shall then be routed to the correct SAP or sub-entity as an MLE-UNITDATA-indication primitive. 

On receipt of a TL-DATA confirm, the MLE shall issue an MLE-REPORT indication primitive to indicate 
successful transmission of the PDU transmitted as a result of the previous TL-DATA request on that 
endpoint identifier. The data transfer sub-entity shall then remove and analyse the MLE PDU header. The 
PDU header indicates the destination SAP. The data contained in the TL-DATA indication shall then be 
routed to the correct SAP or sub-entity as an MLE-UNITDATA-indication primitive. 

1 8.3.5.3.2 Selection of LLC services via TLB-SAP 

There are no services available at the TLB-SAP in the MS. 

Data received via the TLB-SAP is routed to the network broadcast sub-entity and is dealt with in 
subclause 18.3.6. 

1 8.3.5.3.3 Selection of LLC services via TLC-SAP 

a) Locally generated TL-CONFIGURE requests 

The data transfer sub-entity shall supply TL-CONFIGURE requests primitives to the TLC-SAP to inform 
the lower layers of the state of any MM signalling or circuit mode calls in progress. The MLE-Activity 
indicator allows the lower layers to decide when to apply energy economy. 

NOTE: It is possible to apply an energy economy scheme that has been notified to, and 
agreed by, the SwMI. 

The TL-CONFIGURE request shall be sent with the MLE-Activity indicator parameter set when there is 
any explicit or implicit connection active. The TL-CONFIGURE request primitive may only be sent with the 
MLE-Activity indicator parameter cleared when there is no MM or circuit mode call activity. 

An advanced link shall become active when one of the following occurs: 

TL-CONNECT request is sent and MLE is awaiting TL-CONNECT confirm; 

TL-CONNECT response is sent. 
The advanced link shall be considered to be active until one of the following occurs: 

TL-DISCONNECT confirm is received; 

a TL-RELEASE indication is received; 

a TL-RELEASE request is sent. 

A group circuit mode call remains active until it is disconnected by the MS, released by the SwMI or locally 
released (without any signalling with the SwMI). An individual circuit mode call remains active until it is 
disconnected by the MS or released by the SwMI. 

b) Locally received TL-SELECT indications 

Where the MLE receives a TL-SELECT indication via the TLC-SAP indicating that the MAC has been 
instructed to change channels and no response is required, this is dealt with in subclause 18.3.4.3. 

The only case where the MLE is required to respond to a channel change TL-SELECT indication is in the 
case of cell change in announced type 1 cell re-selection. In this case the MLE shall respond with 
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TL-SELECT response containing a parameter which gives the frequency of the main carrier on the new 
cell. 

c) Outgoing messages from MM 

These are generally routed via the attachment management sub-entity (see subclause 18.3.4). 
There are two exceptions to this. 

The first is the MLE-IDENTITIES request primitive which contains the valid ISSI(s) and attached/detached 
GSSIs. The procedures for dealing with this are described in subclause 18.3.5.1 . 

The second is the MLE-INFO request primitive which after the local recording of the subscriber class 
within the data transfer sub-entity is transferred further to the lower layers in a TL-CONFIGURE request 
primitive. 

d) Incoming messages to MM 

These are routed via the attachment management sub-entity (see subclause 18.3.4). 

e) Outgoing messages from CONP and SCLNP 

There are no messages routed from CONP or SCLNP to the TLC-SAP. 

f) Incoming messages to CONP and SCLNP 

There are no messages routed from the TLC-SAP to CONP or SCLNP. 

g) Outgoing messages from CMCE 

On receipt of an MLE-CONFIGURE request primitive, MLE shall pass on the information contained in its 
parameters to layer 2 using TL-CONFIGURE request. 

On receipt of an MLE-IDENTITIES request primitive, MLE shall pass on the information contained in its 
parameters to layer 2 using TL-CONFIGURE request. 

h) Incoming messages to CMCE 

There are no CMCE primitives received on the TLC-SAP. 
1 8.3.5.4 Routing of local control information 

On receipt of an MLE-OPEN request from the MM SAP, the data transfer sub-entity shall issue an 
MLE-OPEN indication to the CMCE, CONP and SCLNP SAPs. The data transfer sub-entity shall then 
open the SAPs and shall permit the transfer of data between layers. If the MLE-OPEN request is received 
whilst the data transfer sub-entity is in state closed then the data transfer sub-entity shall enter state Idle. 
In all other states it shall remain in that state. 

On receipt of an MLE-CLOSE request from the MM SAP the data transfer sub-entity shall relay this as an 
MLE-CLOSE indication to the CMCE, CONP and SCLNP SAPs. The data transfer sub-entity shall then 
close the SAPs and shall not permit the transfer of data between layers. The data transfer sub-entity shall 
enter state closed, and shall remain in that state until it receives an MLE-OPEN indication. 

On receipt of an MLE-BREAK indication from the attachment management sub-entity, the data transfer 
sub-entity shall relay this MLE-BREAK indication to the CMCE and CONP SAPs. The data transfer 
sub-entity shall enter state broken. During a temporary link break data may be buffered in the data 
transfer sub-entity. 

On receipt of an MLE-RESUME indication from the attachment management sub-entity, the data transfer 
sub-entity shall relay this MLE-RESUME indication to the CMCE and CONP SAPs. The data transfer 
sub-entity shall return to its previous state. Any data buffered in the data transfer sub-entity during the 
temporary link break should now be (re)submitted for transmission. 
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On receipt of an MLE-REOPEN indication from the attachment management sub-entity, the data transfer 
sub-entity shall relay this MLE-REOPEN indication to the CMCE and CONP SAPs. The data transfer 
sub-entity shall enter state idle. Any data buffered in the data transfer sub-entity during the temporary link 
break should now be discarded. 

1 8.3.6 Network broadcast sub-entity 

18.3.6.1 Summary 

The system broadcast function broadcasts system information from the SwMI to all MSs. 
There are two formats for this system information: 

immediate system information; 

network broadcast system information. 

The immediate system information is supplied to layer 2 in the SwMI and broadcast on the BNCH and 
BSCH as defined in clause 9. The exact method by which the information is supplied to layer 2 is outside 
the scope of this ETS. At the MS the MLE-PDU shall be received by the network broadcast sub-entity as 
TL-SYNC indication and TL-SYSINFO indication primitives via the TLB-SAP. 

The network broadcast system information and late entry information is supplied to layer 2 in the SwMI 
and broadcast as requested. The exact method by which the information is supplied to layer 2 is outside 
the scope of this ETS. At the MS the MLE-PDU shall be received by the network broadcast sub-entity as a 
D-NWRK-BROADCAST PDU with a TL-UNITDATA indication via the TLA-SAP and data transfer 
sub-entity. The MLE is able to route the network broadcast system information to the network broadcast 
sub-entity by virtue of the PDU header it arrives with, and the late entry information to CMCE-SAP by 
virtue of the PDU header it arrives with. 

The SwMI shall indicate whether or not it supports transmission of the D-NWRK-BROADCAST PDU using 
the "neighbour cell broadcast- element which is transmitted as part of the D-MLE-SYNC PDU. 

System broadcast information can be received whilst the MS is scanning or is camped on a cell. The 
MS-MLE shall ensure that system broadcast information received whilst scanning is applied to the correct 
cell. 

An MS may also prompt the SwMI to transmit the neighbour cell broadcast information by using the 
neighbour cell enquiry service as described in subclause 18.3.6.5. 

18.3.6.2 System information 

The system information is a series of messages that are broadcast at regular intervals from the SwMI to 
the MS MLEs. 

The immediate system information contains the following information: 
MNC; 
MCC; 

LA Code (LAC); 
subscriber class; 
cell service level; and 



late entry information availability. 
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The network broadcast system information in the D-NWRK-BROADCAST PDUs contain a combination of 
the following information: 

frequencies of adjacent cells for cell selection and re-selection; 

parameters for roaming (measurement levels, intervals). 

This information should be used by the MSs to guide the cell selection procedures. 

18.3.6.3 Message formats for system information 

System information messages shall be constructed according to the rules described in subclause 18.4. 
Each network broadcast system information may contain any combination of information elements. 

18.3.6.4 Network broadcast procedures 

On receiving a TL-SYNC indication primitive or a TL-SYSINFO indication primitive via the TLB-SAP, the 
network broadcast sub-entity shall analyse the contents. The information contained within shall either be 
passed to attachment management, e.g. to update cell rankings, and, in the case of a new subscriber 
class bit map, be passed to the data transfer sub-entity. 

1 8.3.6.5 Neighbour cell enquiry procedure 

An MS may prompt the SwMI to transmit the D-NWRK-BROADCAST PDU by sending a U-PREPARE 
PDU to the SwMI. The U-PREPARE PDU shall not contain an SDU or the following optional elements: 
MCC, MNC and LA. The U-PREPARE PDU shall contain the cell identifier element which shall be set to 
"OOOOCV and which shall indicate to the SwMI that the MS is requesting transmission of the 
D-NWRK-BROADCAST PDU. 

NOTE: The MS may request transmission of the D-NWRK-BROADCAST PDU because it has 
yet not received the neighbour cell information and the MS needs this in order to 
initiate cell re-selection procedures. This may occur if the current serving cell signal 
level is falling and the MS cannot wait for the normal D-NWRK-BROADCAST 
broadcast to be sent. 

An MS may not receive the normal D-NWRK-BROADCAST broadcast, for example, as 
a result of being in energy economy and it is sleeping while the 
D-NWRK-BROADCAST is being transmitted by the SwMI. 

MLE shall send the U-PREPARE PDU by issuing a TL-DATA request to layer 2 with the primitive 
parameters set as follows: 

PDU priority shall be set to 3; 

stealing permission shall be set to "steal immediately"; 

the stealing repeats flag shall not be set. 

MLE shall start timer, T370, and shall await the response from the SwMI. The SwMI shall respond by 
transmitting the D-NWRK-BROADCAST PDU which may be individually addressed to the MS using the 
layer 2 acknowledged service or may be sent unacknowledged to a group address or to the broadcast 
address ("all ones" address). 

On reception of the D-NWRK-BROADCAST PDU, the MLE shall reset timer, T370. If timer, T370, expires 
the MS shall assume that the cell enquiry service has failed and shall wait for the SwMI to send the normal 
D-NWRK-BROADCAST broadcast. The SwMI may also respond to the U-PREPARE PDU with a D- 
PREPARE-FAIL PDU which has the "Fail cause" element set equal to "Neighbour cell enquiry not 
available". 

The SwMI shall indicate whether or not the neighbour cell enquiry service is supported using the 
•neighbour cell broadcast" element which is transmitted as part of the D-MLE-SYNC PDU. If the service is 
not supported, the MS shall not attempt to send the U-PREPARE PDU with the cell identifier set to 
■OOOOO2". 
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1 8.3.7 Management sub-entity 

The management sub-entity shall be responsible for communication of management information between 
the MS and the SwMI. MLE PDUs to and from the management sub-entity shall have a protocol 
discriminator set to "HOa". The PDUs shall be transferred between the MS and the SwMI using the TMI 
as the source address on the uplink and as the destination address on the downlink. 

No TETRA management PDUs are defined in this ETS. 

18.4 PDU descriptions 

The following PDU descriptions contain a mapping of the information elements into an MLE PDU 
specifying the length of the element, the type of the element and whether the element is mandatory, 
conditional or optional. The contents of the information elements themselves are further detailed in 
subclause 18.5. 

The information contained in the PDU description tables corresponds to the following key: 

Length: length of the element in bits; 

Type: element type 1 or 2 as defined below; 

C/O/M: conditional/optional/mandatory information in the PDU; 

Remark: comment. 

1 8.4.1 Data transfer PDUs at the TLA-SAP 

1 8.4.1 .1 Protocol discriminator 

The contents of an MLE PDU sent and received at the TLA-SAP shall be determined by a 3 bit protocol 
discriminator. The discriminator shall be the first element field in the MLE PDU. 

The protocol discriminator shall determine the MLE user SAP endpoint, i.e. it is used as routing 
information within the MLE data transfer sub-entity. 

If the protocol discriminator indicates CMCE, MM, CONP or SCLNP, then the MLE shall simply remove 
the protocol discriminator and route the SDU to the relevant upper layer 3 protocol entity. 

If the protocol discriminator indicates TETRA management entity, then the MLE shall remove the protocol 
discriminator and route the SDU to the TETRA management functional entity within the MLE protocol 
entity. 

If the protocol discriminator indicates MLE, then the MLE shall remove the protocol discriminator and 
process the remainder of the PDU according to the MLE protocol. 

18.4.1.2 PDU type 

When the protocol discriminator indicates the MLE protocol, a "PDU type" element shall follow which shall 
indicate the particular MLE protocol PDU type. 

18.4.1.3 MLE service user PDUs 

PDUs which have the protocol discriminator equal to one of the following: MM, SCLNP, CMCE, CONP or 
TETRA Management Entity shall be defined as in table 220. 



Table 220: MLE service PDU layout 



Information element 


Length 


Value 


Remark 


Protocol discriminator 


3 




See subclause 18.5 for element definition 


SDU 


Variable 




MM, CLNP, CMCE, CONP or Management 
Entity SDU 
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The SDUs sent/received at the LMM-SAP, LCLS-SAP, LCMC-SAP, LCO-SAP and to/from the 
management entity shall be transparent to the MLE. The MLE shall simply route these SDUs according to 
the protocol discriminator. 

18.4.1 .4 MLE protocol PDUs 

MLE PDUs which have the protocol discriminator MLE protocol shall comprise both cell change PDUs and 
network broadcast PDUs. 

The general format of the MLE protocol PDU is defined according to table 221 . 

The elements shall be transmitted in the order specified by the table with the top element being 
transmitted first (before interleaving). The content of an information element is represented by a binary 
value and the most significant bit of that binary value shall be transmitted first (before interleaving). 



Table 221: MLE protocol PDU layout 



Information element 


Length 


Value 


Remark 


Protocol discriminator 


3 


101 2 


Specifies an MLE protocol PDU 


PDU type 


3 




Specifies the particular MLE protocol PDU 


Type 1 element (1) 






See element definition for length & values 


Type 1 element (2) 






See element definition for length & values 


...etc. 






...etc. 


Type 1 element (n) 






See element definition for length & values 


Optional bit (O-bit) 


1 


0 


No type 2 elements follow 






1 


Type 2 elements follow 


Presence bit (P-bit) (1) 


1 


0 


The type 2 element (1) is not present 






1 


The type 2 element (1) is present 


Type 2 element (1) 






See element definition for length & values 


Presence bit (P-bit) (2) 


1 


0 


The type 2 element (2) is not present 






1 


The type 2 element (2) is present 


Type 2 element (2) 






See element definition for length & values 


...etc. 






...etc. 


Presence bit (P-bit) (n) 


1 


0 


The type 2 element (n) is not present 






1 


The type 2 element (n) is present 


Type 2 element (n) 






See element definition for length & values 



Element type 1 : 

elements of type 1 shall be identified by their fixed position in the PDU. The elements have fixed 
lengths as specified in the "length" column. Each type 1 element shall either be a mandatory 
element or conditional to a mandatory element. The type 1 elements shall also be placed before 
any type 2 elements. 



Element type 2: 

elements of type 2 are optional and shall be identified by their order within the PDU. If one or more 
type 2 elements are specified for a PDU, there shall be one P-bit for each specified type 2 element 
and each of them shall either indicate "element present" or "element not present". 

When the PDU does not contain (or cannot contain) any type 2 elements, the O-bit shall be present and 
set equal to "0". 

The following rules shall apply for decoding of an MLE PDU: 

DECODE Type 1 Elements; 
DECODE O-bit 

IF O-bit set to "No type 2 elements follow", END. 
ELSE 

DO for all possible type 2 elements 
DECODE P-bit 

IF P-bit set to "Present", decode type 2 element 
END DO; 

END. 



Page 299 

ETS 300 392-2: March 1996 



The PDU type shall be used to map different messages (primitives) coming from the layer 2 at the 
TLA-SAP onto the relevant primitives for the MLE service users and vice versa. Even in PDUs which 
cannot have optional elements, the O-bit shall be present. The only exceptions to this are the 
D-MLE SYNC and D-MLE SYSINFO PDUs. 

1 8.4.1 .4.1 D-NWRK-BROADCAST 

Message: D-NWRK-BROADCAST 
Response to: -/U-PREPARE 
Response expected: 

Short description: Upon receipt from the SwMI, the message shall inform the MS-MLE about 

parameters for the serving cell and parameters for one or more neighbour cells. 

Table 222: D-NWRK-BROADCAST PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 




Cell re-select parameters 


16 


1 


M 




Cell service level 


2 


1 


M 




TETRA network time 


48 


2 


0 




Number of neighbour cells 


3 


2 


0 


note 1 


Neighbour cell information 








note 2 


NOTE 1 : If present, the element shall indicate how many "Neighbour cell information- 
elements follow. If not present, no neighbour cell information shall follow. 

NOTE 2: The element definition is contained in subclause 18.5 which gives the type and 
length for each sub-element which is included in this element. The element shall 
be repeated as many times as indicated by the "Number of neighbour cells- 
element. There shall be no P-bit for each neighbour cell information element 
which is carried by this PDU. 



18.4.1.4.2 D-NEW-CELL 



Message: D-NEW-CELL 
Response to: U-PREPARE 
Response expected: 

Short description: Upon receipt from the SwMI the message shall inform the MS-MLE that it can 

select a new cell as previously indicated in the U-PREPARE PDU. 



Table 223: D-NEW-CELL PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 




Channel command valid 


2 


1 


M 




SDU 








note 


NOTE: The SDU may carry an MM registration PDU which is used to forward register to a 


new cell during announced type 1 cell re-selection. The SDU is coded according to 


the MM protocol description. There shall be no P-bit in the PDU coding for the 


SDU. 
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1 8.4.1 .4.3 D-PREPARE-FAIL 

Message: D-PREPARE-FAIL 
Response to: U-PREPARE 
Response expected: 

Short description: Upon receipt from the SwMI the message shall be used by the MS-MLE as a 

preparation failure, while announcing cell re-selection to the old cell. 

Table 224: D-PREPARE-FAIL PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 




Fail cause 


2 


1 


M 





1 8.4.1 .4.4 D-RESTORE-ACK 

Message: D-RESTORE-ACK 
Response to: U-RESTORE 
Response expected: 

Short description: Upon receipt from the SwMI, the message shall indicate to the MS-MLE an 

acknowledgement of the C-Plane restoration on the new selected cell. 

Table 225: D-RESTORE-ACK PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 




SDU 








note 


NOTE: 


This PDU shall carry a CMCE D-CALL RESTORE PDU which can be used to 
restore a call after cell re-selection. The SDU is coded according to the CMCE 
protocol description. There shall be no P-bit in the PDU coding for the SDU. 



1 8.4.1 .4.5 D-RESTORE-FAIL 

Message: D-RESTORE-FAIL 
Response to: U-RESTORE 
Response expected: 

Short description: Upon receipt from the SwMI, the message shall indicate to the MS-MLE a failure 

in the restoration of the C-Plane on the new selected cell. 



Table 226: D-RESTORE-FAIL PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 




Fail cause 


2 


1 


M 
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18.4.1.4.6 U-PREPARE 

Message: U-PREPARE 
Response to: 

Response expected: D-NWRK-BROADCAST/D-PREPARE-FAIL 

Short description: The message shall be sent on the serving cell to the SwMI by the MS-MLE, 

when preparation of cell re-selection to a neighbour cell is in progress. 

Table 227: U-PREPARE PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 




Cell identifier 


5 


2 


0 




SDU 








note 


NOTE: The SDU may carry an MM registration PDU which is used to forward register to a 


new cell during announced type 1 cell re-selection. The SDU is coded according to 


the MM protocol description. There shall be no P-bit in the PDU coding for the 


SDU. 











18.4.1.4.7 U-RESTORE 

Message: U-RESTORE 
Response to: 

Response expected: D-RESTORE-ACK/D-RESTORE-FAIL 

Short description: The message shall be sent by the MS-MLE, when restoration of the C-Plane 

towards a new cell is in progress. 



Table 228: U-RESTORE PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


PDU type 


3 


1 


M 




MCC 


10 


2 


O 


note 1 


MNC 


14 


2 


O 


note 1 


LA 


14 


2 


o 


note 1 


SDU 








note 2 


NOTE 1 : 
NOTE 2: 


The element is present in the PDU if its value on the new cell is different from that 
on the old cell. 

This PDU shall carry a CMCE U-CALL RESTORE PDU which shall be used to 
restore a call after cell re-selection. The SDU is coded according to the CMCE 
protocol. There shall be no P-bit in the PDU coding for the SDU. 



18.4.2 Broadcast PDUs at the TLB-SAP 

PDUs at the TLB SAP shall be transported using the BNCH and BSCH logical channels. D-MLE-SYNC 
shall use the BSCH logical channel and D-MLE-SYSINFO shall use the BNCH logical channel. 
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18.4.2.1 D-MLE-SYNC 

Message: D-MLE-SYNC 
Response to: 
Response expected: 

Short description: This message shall inform the MS about information that is necessary for 

performing cell re-selection. The message can only be recognised as a MAC to 
MAC message on the broadcast synchronisation channel (BSCH). 

Table 229: D-MLE-SYNC PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


MCC 


10 




M 




MNC 


14 




M 




Neighbour cell broadcast 


2 




M 




Cell service level 


2 




M 




Late entry information 


1 




M 





This PDU shall not contain an "O" bit and shall be 29 bits in length. 

18.4.2.2 D-MLE-SYSINFO 

Message: D-MLE-SYSINFO 
Response to: 
Response expected: 

Short description: This message is used for informing the MS about MLE information for the 

serving cell. The message can only be recognised as a MAC to MAC message 
on the BNCH. 



Table 230: D-MLE-SYSINFO PDU 



Information element 


Length 


Type 


C/O/M 


Remark 


LA 


14 


1 


M 




Subscriber class 


16 


1 


M 




BS service details 


12 


1 


M 





This PDU shall not contain an "0 M bit and shall be 42 bits in length. 

1 8.5 Information elements coding 

18.5.1 Announced cell re-selection types supported 

The element shall define which types of announced cell re-selection are supported by the SwMI. 



Table 231: Announced cell re-selection types supported element 



Information element 


Length 


Value 


Remark 


Announced cell 
re-selection types 
supported 


2 


00 2 


Only announced type 3 is supported 


01 2 


Announced type 2 and type 3 are supported 


10 2 


Announced type 1 and type 3 are supported 


11? 


Announced type 1 and type 2 are supported 
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1 8.5.2 BS service details 

The element shall contain information about which services are supported by the SwMI on a particular 
cell. 



Table 232: BS Service details element 



Information element 


Length 


Value 


Remark 


Registration 




0 


Registration not required on this cell 


1 


Registration mandatory on this cell 


De-registration 




0 


De-registration not required on this cell 


1 


De-registration mandatory on this cell 


Priority cell 


1 


0 


Cell is not a priority cell 


1 


Cell is a priority cell 


Minimum mode service 


— i — 


0 


Cell may use minimum mode 


1 


Cell never uses minimum mode 


Migration 


— i — 


0 


Migration is not supported by this cell 


1 


Migration is supported by this cell 


Roaming 


^ 


0 


Roaming is not supported by this cell 


1 


Roaming is supported by this cell 


TETRA voice service 




0 


Service is not supported on this cell 


1 


Service is supported on this cell 


Circuit mode data service 




0 


Service is not supported on this cell 


1 


Service is supported on this cell 


CONP Service 




0 


Service is not available on this cell 


1 


Service is available on this cell 


SCLNP Service 




0 


Service is not available on this cell 


1 


Service is available on this cell 


Air interface encryption 
service 




0 


Service is not available on this cell 


1 


Service is available on this cell 


Advanced link supported 




0 


not supported on this cell 


1 


supported on this cell 



18.5.3 Cell identifier 



The element shall be used to identify a neighbour cell. The serving cell shall attach a cell identifier to each 
neighbour cell whenever the serving cell broadcasts information about that neighbour cell. The cell 
identifier can then be used subsequently to refer to that neighbour cell. When the SwMI assigns a cell 
identifier, it shall then be able to map this identifier to a physical cell whenever the MS uses the cell 
identifier (for example, in a U-PREPARE PDU). 

The cell identifier may also be set equal to "OOOOOa" to initiate the neighbour cell enquiry procedure which 
prompts the SwMI to send the D-NWRK-BROADCAST PDU when the MS does not yet have the 
neighbour cell information. 



Table 233: Cell identifier element 



Information element 


Length 


Value 


Remark 


Cell identifier 


5 


00000? 


Neiqhbour cell enquiry 






00001? 


Valid cell identifier 






...etc. 


...etc. 






11111? 


Valid cell identifier 
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1 8.5.4 Cell re-select parameters 

The element shall define the threshold parameters for the cell re-selection procedures in the MS. 

SLOW_RESELECT_THRESHOLD is the maximum level above the FAST_RESELECT_THRESHOLD for 
a radio improvable link. 

FAST_RESELECT_THRESHOLD is the maximum level above C1 = "O" for a radio relinquishable link. 
SLOW_RESELECTJHYSTERESIS is the hysteresis for a radio improvable link. 
FAST_RESELECT_HYSTERESIS is the hysteresis for a radio relinquishable link. 



Table 234: Cell re-select parameters element 



Information element 


Length 


Value 


Remark 


SLOW_RESELECT_THRESHOLD 


4 


0000 2 


OdB 


0001? 


2dB 


...etc. 


...etc. 


1111? 


30 dB 


FAST_RESELECT_THRESHOLD 


4 


OOOO2 


OdB 


0001? 


2dB 


...etc. 


...etc. 


1111? 


30 dB 


SLOW_RESELECT HYSTERESIS 


4 


0000? 


OdB 


0001? 


2dB 


...etc. 


...etc. 


1111? 


30 dB 


FAST_RESELECT_HYSTERESIS 


4 


0000? 


OdB 


0001? 


2dB 


...etc. 


...etc. 


1111? 


30 dB 



18.5.5 Cell service level 



The element shall define the level of service a MS may receive in a cell. It may relate to the traffic loading 
in a cell. 



Table 235: Cell service level element 



Information element 


Length 


Value 


Remark 


Cell service level 


2 


00? 


Cell load unknown 






01? 


Low cell load 






10? 


Medium cell load 






11? 


High cell load 



1 8.5.6 Channel command valid 



The element shall indicate to the MS MLE when to initiate a channel change as a result of cell re- 
selection. 



Table 236: Channel command valid element 



Information element 


Length 


Value 


Remark 


Channel command valid 


2 


00? 


Follow channel allocation in MAC header 


01? 


Change channel immediately 


10 2 


No channel change - 
wait for next D-NEW CELL 


11? 


Reserved 
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18.5.7 Fail cause 

The element shall indicate to the MS the failure cause as a result of requesting an MLE service in the 
SwMI. 



Table 237: Fail cause element 



Information element 


Length 


Value 


Remark 


Fail cause 


2 


00? 


Neighbour cell enquiry not available 






01? 


Cell re-selection type not supported 






10? 


Subscriber class not allowed 






11 2 


Restoration cannot be done on cell 



1 8.5.8 Late entry information 

The element shall indicate to the MS whether or not late entry can be supported by the cell. 



Table 238: Late entry information element 



Information element 


Length 


Value 


Remark 


Late entry information 


1 


0 


Late entry not supported 


1 


Late entry available 



18.5.9 LA 



The element shall define the LA in which a cell is located, either the serving cell or a neighbour cell. 



Table 239: LA element 



Information element 


Length Value Remark 


LA 


14 



18.5.10 Main carrier number 



The element shall define the main carrier number for a neighbour cell. See the channel allocation element 
in clause 21 for a full description of carrier numbering. 



Table 240: Main carrier number element 



Information element 


Length 


Value 


Remark 


Main carrier 


12 




Main carrier number of neighbour cell as 
defined in clause 21 
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1 8.5.1 1 Main carrier number extension 

The element shall define extended carrier numbering information. See the channel allocation element in 
clause 21 for a full description of carrier numbering. 



Table 241 : Main carrier number extension element 



Information element 


Length 


Value 


Remark 


Frequency band 


4 




Provision for different frequency bands as 
defined in clause 21 


Offset 


2 


00? 


No offset 






01? 


+ 6,25 kHz offset 






10? 


- 6,25 kHz offset 






112 


+ 12,5 kHz offset 


Duplex spacing 


3 




Provision for different duplex spacing as 
defined in clause 21 


Reverse operation 


1 


0 


Normal 






1 


Reverse 



18.5.12 Minimum Rx access level 



The element shall indicate the minimum received signal level required at the SwMI in a cell, either the 
serving cell or a neighbour cell. 

Table 242: Minimum Rx access level element 



Information element 


Length 


Value 


Remark 


RXLEV_ACCESS_MIN_MCELL 


4 


0000? 


-125 dBm 


0001? 


-120 dBm 


...etc. 


...etc. 


1111 2 


- 50 dBm (5 dB steps) 



1 8.5.1 3 Maximum MS transmit power 

The element shall indicate to the MS the maximum power that is allowed to be transmitted in a cell, either 
the serving cell or a neighbour cell. 



Table 243: Maximum MS transmit power element 



Information element 


Length 


Value 


Remark 


MS_TXPWR_MAX_MCELL 


3 


000 2 


Reserved 






001 2 


15 dBm 






010? 


20 dBm 






011? 


25 dBm 






100? 


30 dBm 






101? 


35 dBm 






110? 


40 dBm 






111? 


45 dBm 



18.5.14 MCC 



The element shall indicate which country a cell is located in. 



Table 244: MCC element 



Information element 


Length 


Value 


Remark 


MCC 


10 
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18.5.15 MNC 

The element shall indicate which network a cell is located in. 



Table 245: MNC element 



Information element 


Length 


Value 


Remark 


MNC 


14 







18.5.16 Neighbour cell broadcast 

The element shall indicate how an MS can obtain information about neighbour cells. The neighbour cell 
information may be broadcast by the SwMI using the D-NWRK-BROADCAST PDU or the MS may use 
U-PREPARE to enquire for the D-NWRK-BROADCAST information. 



Table 246: Neighbour cell broadcast element 



Information element 


Length 


Value 


Remark 


D-NWRK-BROADCAST 


1 


0 


Not supported 


broadcast supported 




1 


Supported 


D-NWRK-BROADCAST 


1 


0 


Not supported 


enquiry supported 




1 


Supported 



1 8.5.1 7 Neighbour cell information 

The element shall contain information about a neighbour cell. 



Table 247: Neighbour cell information element 



Information element 


Length 


Type 


C/O/M 


Remark 


Cell identifier 


5 


1 


M 




Announced cell re-selection types 
supported 


2 


1 


M 




Neighbour cell synchronised 


1 


1 


M 




Cell service level 


2 


1 


M 




Main carrier number 


12 


1 


M 




Main carrier number extension 


10 


2 


O 


note 1 


MCC 


10 


2 


O 


note 2 


MNC 


14 


2 


0 


note 2 


LA 


14 


2 


0 


note 2 


Maximum MS transmit power 


3 


2 


0 


note 2 


Minimum RX access level 


4 


2 


o 


note 2 


Subscriber class 


16 


2 


0 


note 2 


BS service details 


12 


2 


0 


note 2 


Timeshare cell information 


5 


2 


0 


note 3 


TDMA frame offset 


6 


2 


0 


note 4 


NOTE 1 : 

NOTE 2: 
NOTE 3: 
NOTE 4: 


If not present, the "Main carrier number" element shall fully define the frequency of 
the neighbour cell main carrier. The neighbour cell extended carrier numbering 
information shall be assumed to be the same as that of the serving cell. 
If not present, the neighbour cell parameter shall be assumed to be the same as 
that of the serving cell. 

If not present, it shall be assumed that the neighbour cell is not operating in a 
discontinuous mode of operation. 

If present, the neighbour cell shall be synchronised to the serving cell and this 
element shall indicate the frame offset for the neighbour cell. If the cells are 
synchronised and this element is not present, it shall be assumed by the MS that 
the TDMA frame offset = 0. 



For this element there shall be a P-bit for each type 2 element contained within. 
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1 8.5.1 8 Neighbour cell synchronised 

The element shall indicate whether or not the neighbour cell is synchronised to the serving cell. 



Table 248: Neighbour cell synchronised element 



Information element 


Length 


Value 


Remark 


Neighbour cell synchronised 


1 


0 


Neighbour cell is not synchronised 


1 


Neighbour cell is synchronised 



1 8.5.1 9 Number of neighbour cells 



The element shall indicate how many "Neighbour cell information" elements follow. 



Table 249: Number of neighbour cells element 



Information element 


Length 


Value 


Remark 


Number of neighbour cells 


3 


000? 


No neighbour cell information available 




001 2 


Number of "Neighbour cell information" 
elements contained in this PDU 






...etc. 


...etc. 






111 2 


Number of "Neighbour cell information" 
elements contained in this PDU 



18.5.20 PDU type 

The element shall indicate the PDU type for each of the MLE protocol PDUs. The PDU type shall have a 
separate definition for the uplink and downlink directions as shown in the table below. 



Table 250: PDU type element 



Information element 


Length 


Value 


Remark 

DOWNLINK 


UPLINK 


PDU type 


3 


000? 


D-NEWCELL 


U-PREPARE 




001? 


D-PREPARE FAIL 


Reserved 






010? 


D-NWRK-BROADCAST 


Reserved 






011? 


Reserved 


Reserved 






100? 


D-RESTORE-ACK 


U-RESTORE 






101? 


D-RESTORE-FAIL 


Reserved 






110? 


Reserved 


Reserved 






111? 


Reserved 


Reserved 



18.5.21 Protocol discriminator 



The element shall indicate which protocol the PDU belongs to. MM, CMCE, CONP and SCLNP PDUs are 
simply routed by the MLE to the relevant SAP. MLE protocol PDUs are processed by the MLE protocol 
entity and TETRA management entity PDUs by the TETRA management functional entity within the MLE. 

Table 251 : Protocol discriminator element 



Information element 


Length 


Value 


Remark 


Protocol discriminator 


3 


000? 


Reserved 






001? 


MM protocol 






010? 


CMCE protocol 






011? 


CONP protocol 






100? 


SCLNP protocol 






101? 


MLE protocol 






110? 


TETRA management entity protocol 






111? 


Reserved for testing 
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18.5.22 Subscriber class 



The subscriber class element shall be used by the SwMI to indicate which subscriber classes are allowed 
to use this cell. 



Table 252: Subscriber class element 



Information element 


Length 


Value 


Remark 


Class 1 


1 


0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 2 


1 


0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 3 


1 


0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 4 


1 


0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 5 


1 


0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 6 


1 


0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 7 


1 


0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 8 


1 


0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 9 


1 


0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 10 




0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 11 




0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 12 




0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 13 




0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 14 




0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 15 




0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 


Class 16 




0 


Subscriber class not allowed on cell 






1 


Subscriber class allowed on cell 



18.5.23 



TDMA frame offset 



The element shall indicate the TDMA frame offset between the serving cell and a neighbour cell when 
both cells have synchronised carriers. The element may be used for the time-shared mode of operation or 
to indicate the TDMA frame offset for synchronised cells operating in continuous mode. 

Table 253: TDMA frame offset element 



Information element 


Length 


Value 


Remark 


TDMA frame offset 


6 


000000? 


0 frame offset 






000001? 


1 frame offset 






...etc. 


...etc. 






100011? 


35 frame offset 






100100? 


Reserved 






...etc. 


...etc. 






111111? 


Reserved 
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If FNn and FNs denote the TDMA frame number of the neighbour cell and of the serving cell respectively, 
then: 

FNn={FNs - 1 +TDMA frame offset)mod 18 + 1; (77) 
where Fnn= 1...18and FNs - 1 ...18. 
18.5.24 TETRA network time 

The element shall indicate the absolute TETRA network time to be used for time stamping in the SCLNP 
protocol. 



Table 254: TETRA network time element 



Information element 


Length 


Value 


Remark 


Network time 


24 




note 1 


Local time offset 


24 




note 2 


NOTE 1 : 
NOTE 2: 


Zero time (000000i 6 ) is defined as 00:00 hours, Universal Time Co-ordinates (UTC 
time) on January 1 st of every year. 

Each increment of this element above a value of zero shall correspond to a two 
second increment of the absolute network time. 
The values, F142FFie to FFFFFEie, are reserved. 

The value, FFFFFFie, is reserved and shall be used to indicate an invalid value of 
timestamp in the event of network malfunction. 

The local time offset is coded as a signed integer and indicates the difference 
between the local time and the network time. The step size is the same as for the 
network time (i.e. two seconds) the maximum permissible offset shall be +/- 24 hours. 
The value, FFFFFFi fi , is reserved and shall be used to indicate an invalid offset. 



18.5.25 Timeshare cell information 



The element shall indicate the mode of discontinuous operation for a neighbour cell. The "Discontinuous 
mode" field shall indicate which of the three types of discontinuous mode is in use. 

If the mode is MCCH sharing, the "Reserved frames" sub-element shall indicate how many frames are 
reserved for that neighbour cell. 

If the mode is not MCCH sharing, the "Reserved frames" sub-element shall be ignored by the MS. 



Table 255: Timeshare cell information element 



Information element 


Length 


Value 


Remark 


Discontinuous mode 


2 


00p 


Reserved 


01p 


Carrier sharing 


10 2 


MCCH sharing 


11 2 


Traffic carrier sharing 


Reserved frames per two multiframes 


3 


000p 


1 frame reserved 


001 p 


2 frames reserved 


01 0 2 


3 frames reserved 


011p 


4 frames reserved 


100? 


6 frames reserved 


101p 


9 frames reserved 


110 2 


12 frames reserved 


111 ? 


18 frames reserved 



18.6 Timers 



1 8.6.1 Timer T370 - cell re-selection preparation response time 



This timer shall define the maximum time MLE shall wait for a response to U-PREPARE. The timer, T370, 
shall be of 5 seconds duration. 
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1 9 Layer 2 overview 

19.1 Introduction 

This clause gives an overview of the V+D air interface layer 2 (Data Link Layer (DLL)) which is further 
defined in the following four clauses. It does not imply any requirement for the testability of any of the 
functions described. 

The descriptions in this clause do not imply a specific implementation, but are provided for the guidance of 
the reader in understanding the operation of layer 2. 

1 9.2 Layer 2 architecture 

The model of the DLL comprises two sub-layers: the LLC entity and the MAC entity. The basic 
functionality of these entities are as summarised in ETS 300 392-1 [11], clause 6 and the services offered 
to the upper layer, the MLE, are explained in detail in clause 20. The error control schemes (FEC, CRC) 
are described in clause 8. 

The following description applies to the protocol model of the DLL. The internal boundaries between the 
layers and sub-layers are not testable and do not imply any specific implementation, but are rather used 
for the description of the model. Throughout this subclause the word "shall" is used for describing the 
SAPs for traceability reasons in the protocol model, but those SAPs are not testable. 

1 9.2.1 Access to the DLL 

Figure 75 shows the model of the DLL, its internal subdivision and its interaction with the upper layer 
(MLE) and lower layer (physical layer). 

In the protocol model, the DLL shall provide services to the MLE through SAPs supporting different 
functions: 

TLA-SAP for all signalling messages; 

TLB-SAP for broadcasting system information; and 

TLC-SAP for layer management, status and configuration via data base access. 

Internal communication between LLC and MAC shall use SAPs, namely TMA-SAP, TMB-SAP and 
TMC-SAP. They shall correspond to the separation between signalling, broadcast and layer management, 
as can be seen from the upper layer (MLE). Primitives and parameters are used for protocol description to 
exchange information at this internal boundary (LLC-MAC). The upper MAC layer shall contain MAC 
protocol functions (see clause 23). 

There shall be a (virtual) SAP TMV-SAP inside the MAC layer to allow a protocol description using 
primitives and logical channels. The selection of a specific logical channel triggers specific channel coding 
at the lower MAC, which is devoted to the channel coding (see clause 8). 

The SAP TP-SAP shall be used for communication between MAC and Physical Layer (PL). To exchange 
information at the TP-SAP, pre-formed subslots and blocks with burst type indication shall be used (see 
clause 9). 

The TMD-SAP shall be used to support traffic in circuit mode. It shows clearly that no LLC functionality 
shall be expected in circuit mode. However, subclause 19.4.3.2 describes how some traffic capacity may 
be stolen for signalling purposes in circuit mode. 
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Figure 75: Layer 2 reference architecture 



1 9.2.2 Information flow inside the DLL 



The two types of communications links for TLA-SAP support on the DLL each have a specific quality of 
service. Before any communication establishment, one link shall exist whenever BS control channel 
monitoring is possible. This link is called the basic link and it offers a pre-defined quality of service which 
minimises the LLC overhead over the air interface. A more powerful link may exist upon request. It is 
called the advanced link and it offers a more reliable and better service, especially for packet data transfer 
(see clause 22). When an advanced link is established, the basic link shall remain available. They may 
share the same timeslot in the multiframe structure. 



Illustrations of the layer 2 functions applied to the information content present at the TLA-SAP are given 
on figure 76 and figure 77. On the left hand side, references to the relevant protocol layers are provided. 
The "other parameters" from the MLE may either be mapped into the LLC PDU or used by the DLL (e.g. 
priority). 

The advanced link offers segmentation and error control using a Frame Check Sequence (FCS). The 
advanced link may be used for more reliable and efficient exchange of large amount of data as in, for 
example, packet data transfer. 

it is mandatory for the MS to support the basic link, whereas it is optional for the MS to support the 
advanced link. 



NOTE: The MAC scheme on figure 76 and figure 77 does not display the exact multiframe 
structure nor the random access procedure (see clause 23). 
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Figure 76: Layer 2 data structure for basic link (typically layer 3 signalling messages) 
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Figure 77: Layer 2 data structure for advanced link (e.g. packet data) 
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19.2.2.1 Basic link 

The basic link should be used for general signalling messages (e.g. from CMCE or MM). The basic link 
offers the following services: 

acknowledged message transmission; 

unacknowledged message transmission; 

un-numbered fragmentation of longer messages; 

optional extended error control using an FCS (e.g. for long messages that require fragmentation). 

The principal basic link data structure without fragmentation is shown in figure 76. The protocol is defined 
in detail in clauses 22 and 23. 

19.2.2.2 Advanced link 

An advanced link should be used if a larger amount of data is to be transferred (e.g. for packet data 
transmission) or if a better service is required. The service of an advanced link is negotiable at the set-up 
phase. The advanced link offers the following services: 

acknowledged message transmission; 

unacknowledged message transmission for point-to-multipoint transfer in the downlink; 
window mechanism; 

numbered segmentation of longer messages; 

selective re-transmission for point-to-point transfer; 

selective re-assembly for point-to-multipoint transfer; 

extended error control using a FCS. 

The advanced link data structure is shown in figure 77. The protocol is defined in detail in clauses 22 
and 23. 

1 9.2.2.3 Seg mentation and fragmentation 

There are two methods of sending a long TL-SDU defined in this ETS: fragmentation and segmentation, 
which are defined in detail in clauses 23 and 22. Fragmentation may be performed in the MAC for a basic 
link while segmentation may be performed in the LLC for an advanced link (see figure 78). 

Fragmentation shall be used for the basic link in case of an SDU exceeding the available capacity in the 
MAC (see figure 79). Fragments are not numbered so they shall be sent in sequence. No segmentation 
shall be performed by the LLC for the basic link. 

For the advanced link, the LLC shall segment long data into segments (see figure 77). Each of them shall 
be individually recognisable by its LLC header. The segment length should match the MAC transmission 
unit (MAC block). As a segment is defined as the unit of re- transmission, fragmentation should not be 
used for advanced link messages. 
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Figure 78: Segmentation and fragmentation in the DLL 
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Figure 79: Fragmentation of long SDU in the MAC layer 
19.2.3 Sub-layers 

A detailed DLL illustration for peer-to-peer information exchange is presented in figure 80. The path 
followed by the information flow is shown from the C-plane SAPs - namely TLA and TLB. Information shall 
enter the MAC through the corresponding TMA and TMB SAP. The U-Plane information shall enter the 
MAC directly through the TMD-SAP. In either case, by using the TMV-SAP service primitive, the 
information shall then be placed into the appropriate logical channel and transmitted to the physical layer 
on the assigned timeslot in the multiframe. 
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Figure 80: DLL protocol illustration for the MS side 



The information for layer management flows through the TLC-SAP to the LLC and MAC and further down 
to the physical layer. 

In figure 80 an example is shown in which some LLC links (numbered from 1 to 4) are set-up on the MS 
side. 



NOTE: Four links are considered as a possible scenario, but it is not mandatory for an MS to 
support multiple links. 

Link 1 uses the timeslot 1 in the multiframe structure in the upper MAC. Timeslot 1 is used for traffic 
coming from the TMD-SAP. The first occurrence of this traffic is stolen by link 1 . Link 2 is used to send a 
signalling message in the uplink on timeslot 3 (in this example a set-up of an advanced link). After that 
message exchange, link 4 is the newly set-up advanced link using timeslots 3 and 4 to increase the 
throughput. The link 3 has been set-up, but is not in use currently (no data to send and no resource 
allocated). Finally, some broadcast information are received under the TxB-SAP in timeslots 1 and 2 of 
the last shown frame. 



The various logical channels involved in this communication exchange are shown at the TMV-SAP. At the 
lower MAC, a specific channel coding is applied for each of them. All information in the MAC not related to 
layer management shall be exchanged to/from the physical layer through the TP-SAP. 



Each sub-layer should contain its own layer management. 
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19.2.3.1 LLC sub-layer 

The LLC shall deal with the LLC link establishment and maintenance for the C-plane under the TLA-SAP. 
From the MLE point of view, there may be multiple LLC instances, each dealing with a specific quality of 
service and identified by a number corresponding to the end-point identifier, see figure 80. The basic link 1 
shall be available when MS has synchronised to the BS. In addition to the basic link, the MLE may request 
a higher quality of service from the LLC, and the LLC then may set-up an advanced link or links as 
required depending on the capabilities of the physical layer of the MS. Each advanced link shall use a 
fixed resource at the MAC layer, which may be shared by a basic link. 

The number of simultaneous links in a MS depends on its capability to use multiple timeslots in a frame. 
Up to 4 independent advanced links may be set-up in a frame. Then, up to 4 basic links may be 
associated with the corresponding advanced links. (Scanning a different frequency or cell in search for a 
control channel uses a different link). 

Under the TLB-SAP, there is no LLC functionality and the MLE SDU is passed directly to/from the 
TMB-SAP, Therefore, peer-to-peer information exchange between LLC entities does not exist and there 
exists no LLC PDU for the broadcast under the TLB-SAP. 

The TLC-SAP shall be used for layer management and layer-to-layer control communication. 

19.2.3.2 MAC sub-layer 

The main functionalities of the MAC are channel access control, radio resource control, data transfer and 
error detection. Encryption over the air interface shall be performed in the upper MAC when required. 

The LLC links defined at the TLA-SAP shall enter into the MAC using the TMA-SAP. Logical channel 
allocation and multiplexing shall be performed internally by the MAC. From the protocol point of view, the 
upper MAC shall communicate with the lower MAC by means of primitives through logical channels. From 
the architecture point of view, the choice of the logical channels permits selecting among different means 
of data protection (channel coding) which are part of the lower MAC. But as far as the upper MAC protocol 
is concerned, this lower level functionality has no impact on the content of the message. 

After the set-up of a circuit mode speech or data call, signalling messages may use the ACCH or may use 
the traffic channel stealing mechanism (Stealing Channel STCH). 

Figure 80 illustrates how signalling from the LLC link 1 shares a timeslot with user traffic from U-plane by 
stealing and using the STCH logical channel. The user plane traffic uses the TCH logical channel. The 
broadcast information flowing via TMB-SAP may use specific BSCH logical channel or signalling logical 
channel SCH. The MAC layer allocates 2 timeslots (2 x SCH) for the LLC instance 4 using an advanced 
link providing a higher transfer rate. All logical channels are then encoded at the lower MAC layer as 
defined by the logical channel (refer to clause 8). 

19.2.4 Logical channels 

1 9.2.4.1 Logical channels at the LLC-SAP 

The MLE communicates to the LLC by using the relevant SAPs. Multiple LLC instances may be seen 
through the TLA-SAP. The MLE may choose to send a request on any available link, taking into account 
the associated quality of service. 

1 9.2.4.2 Logical channels at the MAC-SAP 

The LLC and U-plane shall communicate with the MAC via the relevant SAPs. The TMA-SAP shall be 
used for signalling, the TMB-SAP shall be used for downlink broadcast, the TMC-SAP shall be used for 
layer management and the TMD-SAP shall be used for circuit mode traffic and user signalling. 
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19.2.4.3 MAC internal logical channels 

The logical channels may be separated into two categories: 

1) traffic channels carrying U-plane information (circuit mode data and voice) plus end-to-end user 
signalling information. These shall carry information which is exchanged via the TMD-SAP at the 
MAC boundary; 

2) control channels carrying C-plane information (control messages and packet data). These shall 
carry information which is exchanged via the TMA- and TMB-SAP at the boundary between MAC 
and LLC. 

The following logical channels are defined within the upper MAC: 

Control Channel comprising: 

Main Control Channel (MCCH); 

Common Secondary Control Channel (Common SCCH); 

Assigned Secondary Control Channel (Assigned SCCH). 

These channels shall carry control information appearing at the TMA-SAP addressed to MS not 
involved in a circuit mode call. Refer to clause 23. 

ACCH comprising: 

FACCH; 

STCH; 

(S)ACCH. 

These channels shall carry control information appearing at the TMA-SAP intended for MS involved 
in a circuit mode call. 

Broadcast Common Control Channel (BCCH) comprising: 

Broadcast Synchronisation Channel (BSCH); 
Broadcast Network Channel (BNCH). 

These channels shall carry the system broadcast information appearing at the TMB-SAP. 

1 9.2.4.4 Logical channels at the lower MAC 

Logical channels shall offer different physical paths to the information depending on the chosen error 
control scheme among those defined in clause 8. 

The following generic logical channels shall be available at the lower MAC boundary (see figure 81 and 
figure 82): 

AACH; 

Broadcast Synchronisation Channel (BSCH); 

Signalling Channel (SCH); 

Traffic Channel (TCH); 

Stealing Channel (STCH); 

Common Linearisation Channel (CLCH). 

As far as possible, this ETS avoids defining specific physical architectures, but proposes instead to 
explain operation of the MAC sub-layer in terms of the functional blocks and logical channels. This 
reference model architecture applies equally to MSs and BSs. MSs transmission and reception are shown 
in figure 81 and figure 82 respectively. 
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Figure 81 : MAC sub-layers and logical channels for MS uplink transmission 
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Figure 82: MAC sub-layers and logical channels for MS downlink reception 

Tables 256 and 257 provide a summary of the logical channels shown in the previous figures. The 
information mapping on these logical channels is presented starting with the MAC layer SAPs down to the 
physical bursts and blocks. 
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Table 256: Mapping between TMx-SAP and MAC logical channels 



SAP 


Definition 


Loaical 
channel in 
TMV-SAP 


Definition 


TMA 


main or secondary control channel 

1 ■ lull 1 wl wwwvi 1 VJVA 1 J ■ VI IUI II IWI 


SCH/F 

SCH/HD 

SCH/HU 


sianallino channel (full slot) 
signalling channel (1/2 slot downlink) 
signalling channel (1/2 slot uplink) 


fast associated control channel 
slow associated control channel 


SCH/F 

SCH/HD 

SCH/HU 


signalling channel (full slot) 
signalling channel (1/2 slot downlink) 
signalling channel (1/2 slot uplink) 


stealing channel (signalling) 


STCH 


stealing channel (signalling) 


TMD 


traffic channel (circuit mode) 


TCH 


traffic channel (circuit mode) 


stealing channel (user signalling) 


STCH 


stealing channel (user signalling) 


TMB 


broadcast synchronisation channel 


BSCH 


broadcast synchronisation channel 


broadcast network channel 


BNCH on 
SCH/HD 


signalling channel (1/2 slot downlink) 




access assignment channel 
(generated inside the upper MAC) 


AACH 


access assignment channel 




common linearization channel 
(generated inside the upper MAC) 


CLCH 


common linearization channel 



Table 257: Mapping between MAC logical channels and physical layer bursts 



Logical 
channel in 
TMV-SAP 


Definition 


Physical burst 


Definition 


SCH/F 


full slot signalling channel 


NDB, NUB 


normal downlink burst, 
normal uplink burst 


SCH/HD 


half slot downlink signalling channel 


NDB+SF 
BKN2 of SB 


normal downlink burst and slot flag 
2nd half of synchronisation burst 


SCH/HU 


half slot uplink signalling channel 


CB 


control uplink burst 


STCH 


stealing channel 


NDB+SF, 
NUB+SF 


normal downlink burst and slot flag, 
normal uplink burst and slot flag 


TCH 


traffic channel 


NDB, NUB 


normal downlink burst, 
normal uplink burst 


BSCH 


broadcast synchronisation channel 


SB 


synchronisation burst 


AACH 


access assignment channel 


BBK 


broadcast block 


CLCH 


common linearization channel 


LB 


linearization burst 



1 9.2.5 Lower layer management at the DLL 

The TETRA protocol architecture, ETS 300 392-1 [11], clause 6 shows how the lower layer management 
entity is incorporated into all lower layers and is accessible via SAPs TXC-SAP as shown in figure 75 and 
figure 80 for the lowest layers. Those access points enable access to information such as measured 
values, status, general information. The services related to the management of LLC and MAC are 
described in clause 20. 

The DLL should have its own set of functions and measured values. These parameters shall be 
exchanged using a set of primitives as described in the appropriate clause, namely clauses 23 and 22. 
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1 9.3 System modes of operation 

This subclause provides an outline description of system modes of operation and their impact on layer 2. 

19.3.1 Norma! mode 

In the normal mode of operation, the common control channel on the main carrier shall always be the 
MCCH and shall always be present in timeslot 1 of all frames 1 to 18. This common control channel shall 
be used for all common control signalling. All MSs shall be able to locate and listen to the downlink 
transmissions of the MCCH. The BS shall transmit on all downlink slots of the main carrier during normal 
mode. 

19.3.2 Extended mode 

A BS may have more than one control channel operational at a time. The ways to operate this may be as 
follows: 

a common SCCH, which has the same functionality as the MCCH but may be used only by a sub- 
set of the user population; 

an ASCCH used to continue control signalling after the initial random access or paging message. 

The BS may operate ECCHs comprising more than one timeslot per TDMA frame. The ways to operate 
this may be as follow: 

an extended random access channel available on the uplink of the main carrier, allowing additional 
random access opportunities; 

multi-slot SCCHs used to provide a higher transfer rate, if requested for an advanced link. A multi- 
slot SCCH may only be used as directed by the BS after an initial access or paging message. 

NOTE: The MCCH and any SCCHs having the same functionality as the MCCH (for a subset 
of the population) cannot be extended to more than one timeslot per TDMA frame. 

1 9.3.3 Minimum mode 

Minimum mode allows a BS to assign all four timeslots on the main carrier for traffic or dedicated control 
purpose. In this mode, only frame 18 can be used for common control without disturbing the established 
services. A BS enters minimum mode when all four downlink timeslots on the main carrier are assigned 
so that there is no common control channel available in timeslot 1 . 

1 9.3.4 Discontinuous transmission mode 

A BS may transmit discontinuously on the main carrier when it operates in one of the following time 
sharing modes. 

1 9.3.5 Time sharing mode 

In the time shared mode, multiple BSs may use the same radio resource for control channel purposes in a 
co-ordinated manner. 

1 9.3.5.1 Carrier sharing mode 

In carrier sharing mode, one carrier frequency shall be shared among up to four cells, each cell being 
allocated at least one timeslot of the TDMA frame (see clause 9 for more details). 

19.3.5.2 MCCH sharing mode 

In the MCCH sharing mode, the MCCH shall be shared among several cells in a manner under the control 
of the infrastructure (see clause 9 for more details). 
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1 9.4 MS modes of operation 

19.4.1 Idle mode 

The idle mode shall be the state of the registered MS not involved in any particular transmission. It shall 
consist of listening to the MCCH or to any signalling channel the MS could have been told by the SwMI. 
The MS shall be capable of monitoring adjacent cell in this mode as described in clause 23. 

1 9.4.2 Signalling and packet mode 

1 9.4.2.1 Common CCH 

This channel shall support common signalling for all MSs (see clause 23). In a system, there may be in 
addition to the MCCH one or more SCCHs. By default, the MS shall listen to the MCCH for paging and 
other signalling (see subclause 19.4.5 for energy economy). 

19.4.2.2 Secondary CCH 

These channels shall be used to increase the capacity of the common control channel. They may have 
the same functionality as the MCCH for a subdivision of the population or they may be devoted to support 
only certain type of transmission, e.g. packet mode data. In that respect, they may serve as a control 
channel dedicated to packet data transmission (see clause 23). The BS shall command MS to use 
appropriate control channel by allocating additional resources or by commanding MS to go to a certain 
control channel (refer to subclause 19.3.2). The BS shall command MS to use the appropriate control 
channel, either by a broadcast message indicating the number and location of common SCCHs in 
operation, or by commanding certain MS to go to an ASCCH. 

NOTE: A BS could use an assigned SCCH for continuing signalling for circuit mode call set- 
up. 

The BS may decide to assign an SCCH for advanced link packet data transmission. 
There are different possible methods of usage. 

EXAMPLE: a) the BS may use an assigned SCCH for only one advanced link (i.e. 

similar to the usage of a channel for a circuit mode call); or 

b) the BS may use an assigned SCCH as a general packet data channel, 
supporting advanced links for many MSs, where each MS may be 
offering/receiving data packets at a low rate or intermittently. 

MS operation is the same in both cases. The channel usage is scheduled by the 
BS; and MSs transmit only under BS control (by random access or reserved 
access). An MS remains on the channel while its advanced link is connected, 
even though the MS is not necessarily using the link all the time. After a pause, 
the MS uses random access when it wishes to continue transmission. 

An advanced link can also use a common control channel or, for MSs in a circuit 
mode call, an ACCH. However, if common control channel, the normal control 
channel performance may be degraded. 

19.4.2.3 ACCH 

This channel shall be used for signalling in conjunction with an established circuit (traffic channel). That 
signalling may be independent of the call the control channel is associated with. The lower MAC should be 
configured as shown in figure 83. Depending on the circuit mode call type and the capabilities of MS, the 
ACCH may be available during timeslots in frames 1-17 (if they are not being used for traffic), and it is 
always available during the 18th frame; refer to clause 23. The first one is called Fast Associated Control 
Channel (FACCH) and the latter Slow Associated Control Channel (SACCH). The MS shall listen to the 
ACCH under control of the BS; refer to subclause 19.4.4. 
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19.4.2.4 Full and half slot signalling 

In figure 83 and figure 84, full (SF=0) or half slot (SF=1) downlink signalling shall be indicated by the 
appropriate slot flag (SF). The slot flag (SF) shall be a change between two training sequences, as 
described in clause 9. Downlink control messages may usually occupy a full slot, but the system 
broadcast channels (BxCH) shall be all one half slot long to enable them to be transmitted in frame 18 
(BSCH or SCH/HD; Cf. clause 9). 

For the MS transmission on the uplink, use of a subslot for initial access shall be indicated by a third 
training sequence corresponding to the logical channel SCH/HU as described in clause 9. 

Uplink control messages are usually sent within a subslot using the logical channel SCH/HU. However, for 
packet data or when using fragmentation, the MS may need to use full slots for the transmissions 
subsequent to the initial access. The allocation of MS uplink timeslots shall be under the control of BS. 

Once the MS has switched into traffic mode, all transmissions shall be done over an entire timeslot. 
Distinction between full slot for traffic and half slot to indicate that the first half slot has been stolen for 
signalling purposes shall be indicated by a change between the two training sequence, in a manner 
identical to that used for the downlink. 
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Figure 83: Configuration in signalling and packet mode 
Traffic mode 



19.4.3.1 Normal operation 

The traffic mode may be either speech or data circuit operation. The logical channels in use shall be TCH 
(traffic channels) for frames 1 to 17. Full slots (Slot Flag = 0) shall normally be used for traffic. Frame 18 
shall be used for signalling only. 
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Figure 84: Configuration in traffic mode for frames 1 to 17 



1 9.4.3.2 Stealing mechanism 

When in traffic mode (either speech or data circuit), capacity may be stolen for signalling purposes. This 
shall leave the current mode of operation unchanged. The appearance of half slot (SF=1) in the 
transmission shall indicate that stealing has occurred. Half slot (SF=1) operation shall be indicated by a 
change in the appropriate training sequence as described in clause 9. The header of the first half of the 
slot shall indicate whether the other half has also been stolen or if it belongs to the normal traffic circuit. 
The header shall contain an information on the intended destination of the signalling message: either C- 
plane or U-plane signalling. Stealing occurrence shall be locally reported to the U-plane application at the 
TMD-SAP (see figure 84). 



This mechanism shall apply to both BS and MS transmissions. 
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19.4.4 



Selection of the mode of operation 



During a transaction, the MAC shall be considered to be switched into one of the following modes of 
operation: 

signalling mode; or 

traffic mode. 

The selection mechanism is presented in figure 85. The default mode of the MAC layer shall be signalling 
mode (selector in position 1 on figure 85). The BS shall send CC messages to change the mode of 
operation in the MS MAC layer. This change shall be reflected from the CC into the MAC using layer 
management communication internal to the MS. In case of accidental loss of the CC message, a fall-back 
mechanism is specified using the AACH indications. 

When stealing is initiated in circuit mode operation (either by the MS or the SwMI), the logical channel 
shall be temporarily taken (fully or partially) on a half slot by half slot basis for signalling purposes. 
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Figure 85: Selection of the configuration for the current mode of operation 

If traffic mode is selected, then the mode selector switch shall be set accordingly in the MS and in the 
SwMI. 

In case of independent uplink and downlink assignment (e.g. to cover inter-site calls), the selector may be 
duplicated for uplink and downlink operation (i.e. for MS transmission and reception). Still, the selectors 
shall be set accordingly in the MS and SwMI. 

NOTE: Traffic mode applies only to frames 1 to 17. Both MS and BS are in signalling mode on 
frame 18. 



19.4.5 



Energy economy mode 



On the MS request, the BS MM may command the MS to energy economy mode. The start of the energy 
economy shall be indicated by the BS. The MS shall then follow a regular cycle of N timeslots in energy 
economy for 1 timeslot in reception. During energy economy mode, the MS shall remain synchronised to 
the BS transmission. 



19.4.6 



Support of concurrent calls 



Depending on the class of the mobile, concurrent calls may be supported by LLC (see clause 22) and 
MAC (see clause 23) protocols. 
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1 9.4.7 Support of air-interface encryption 

The support of encryption is optional and shall be indicated as part of the MS capabilities (i.e. in the class 
of MS). 

If this mode is supported, the MAC shall encrypt signalling messages as instructed by the upper layers on 
a message basis. Encrypted messages shall be indicated in the MAC header in order to enable the 
receiving end to de-encrypt the message content. 

The MAC may in addition encrypt the content of the half slots coming from the TMD-SAP. This may also 
apply to an established encrypted call. The encrypted speech shall then be encrypted once more in the 
MAC. In this case, encryption synchronisation messages shall also be encrypted at the MAC level and 
decrypted before being passed through the TMD-SAP at the receiving side. 

19.5 Scenarios for primitives and PDU transfer on the air interface 

Figure 86 and figure 87, and figure 88 and figure 89 show example scenarios illustrating message 
exchanges for call set-up. Figure 86 and figure 87 show the primitives and PDUs on a calling MS air 
interface. Figure 88 and figure 89 show the primitives and PDUs on a called MS air interface. 

NOTE: Some features represented here may be optional. 

Refer to clauses 20 and 21 for definition of primitives and elements, and PDUs respectively. Refer to 
clauses 11 and 14 for the call set-up definition. The involved MLE, LLC and MAC protocols are found in 
clauses 18, 22 and 23, respectively. 
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Figure 86: Primitives and PDUs on the calling MS air interface 
for an individual call with direct set-up signalling - Calling MS side 
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Figure 87: Primitives and PDUs on the calling MS air interface 
for an individual call with direct set-up signalling - SwMI side 
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Figure 88: Primitives and PDUs on the called MS air interface 
for an individual call with direct set-up signalling - SwMI side 
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Figure 89: Primitives and PDUs on the called MS air interface 
for an individual call with direct set-up signalling - Called MS side 
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20 Layer 2 service description 

20.1 Introduction 

This clause describes the services offered by the layer 2 (see clauses 22 and 23) of the V+D TETRA air 
interface (see ETS 300 392-1 [11], clause 6). The service description is done in terms of SAPs, primitives 
and their parameters. In this clause the word "shall" is used with SAPs, service primitives and parameters 
for traceability reasons in the protocol model, but those SAPs and primitives are not testable. As this 
applies inside a MS at non-specified reference points (see ETS 300 392-1 [11], clauses 4 and 5), the 
following description does not imply any specific implementation. 

20.2 Layer 2 service description 
20.2.1 LLC-SAPs 

The model of the DLL comprises two sub-layers, the LLC and the MAC. The layer architecture is 
presented in clause 19. 

Layer 2 shall provide services to the MLE through three SAPs, TLA, TLB, TLC as shown in figure 90. 
These services are defined in terms of primitive actions and events of the service, parameters associated 
with each primitive action and event, interrelationship between primitives and the valid sequences of those 
actions following the ISO model ISO 8348 [5]. 

NOTE 1 : The MLE layer is also called "service user" in the layer 2 descriptions. 

Signalling Broadcast Layer management 



p — >=p — 

S-SAP TLC-SAP 
Figure 90: SAPs at the MLE-LLC boundary 

The SAPs in this model are: 
TLA SAP for signalling: 

this SAP shall be used for data transfer and for control of the data transfer. The services are 
described in tables 265 and 266; 

TLB SAP for broadcast: 

this SAP shall be used for broadcasting purposes; 

TLC SAP for layer management: 

this SAP shall be used for the local control related to the cell selection/re-selection in the 
MLE. In this model it is also used for local layer management inside one protocol stack. For 
example, it may be used for passing values (e.g. valid addresses, MNC, MCC) between the 
service user and the protocol layer 2. 

NOTE 2: The peer-to-peer services provided by the TLA SAP and the TLB SAP correspond to 
services between one BS and one or several MSs. The services provided by the TLC 
SAP correspond to the services within a MS. 



MLE 



LLC 



T 

TLA-SAP 
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20.2.2 MAC SAPs 

The MAC shall provide three SAPs to the LLC, TMA-SAP, TMB-SAP and TMC-SAP. Their role is the 
same as the corresponding TLA-SAP, TLB-SAP and TLC-SAP. 

In addition to these, the MAC shall provide an additional SAP to the U-plane, the TMD-SAP. The services 
offered at this SAP are illustrated in clause 19 and described in clause 23. 

20.2.3 Generic primitive types 

Four different types of primitives are used in this protocol model as defined in ISO 8348 [5] and further 
explained in ETS 300 125 [12]. TETRA specific explanations are shown below in the notes. 

The REQUEST primitive type shall be used when a higher layer is requesting a sen/ice from the lower 
layer. 

The INDICATION primitive type shall be used by a layer providing a service to notify the higher layer of 
any specific activity which is service related. The INDICATION primitive may be the result of an activity of 
the lower layer related to the primitive type REQUEST at the peer entity. 

NOTE 1 : Primitives at the TxC-SAP are not normally directly related to any data transfer service. 

The RESPONSE primitive type shall be used by a layer to acknowledge receipt, from a lower layer, of the 
primitive type INDICATION. 

NOTE 2: In TETRA, a RESPONSE primitive may be used with upper layer data in order to force 
transportation of acknowledgement and service user data (TL-SDU) in the same 
transmission. The TL-SDU will then be placed in the PDU containing the 
acknowledgement. 

The CONFIRM primitive type shall be used by the layer providing the requested service to confirm that the 
activity has been completed. 

NOTE 3: The CONFIRM primitive may be the result of an activity of the lower layer related to the 
primitive type RESPONSE at the peer entity and in that case it may contain service 
user data (TL-SDU). 

20.2.4 Parameters definition for LLC and MAC service primitives 

20.2.4.1 Address type 

This shall be used by the service user to indicate to the MAC which address type will be used for 
transmission. It shall be used to distinguish between a user address (i.e. SSI), a management address 
(i.e. SMI) or an un-exchanged address (i.e. USSI). 

20.2.4.2 Channel 

The channel parameter shall identify the frequency of the channel the MS shall use for the requested 
service or that layer 2 has used for the indicated service. 

20.2.4.3 Channel change accepted 

This parameter shall be used by the higher layers to indicate that the MAC should accept a group 
addressed channel allocation. 

20.2.4.4 Channel change response required 

This parameter shall be used for the MAC to indicate to the higher layers that a group addressed channel 
allocation command was received with a particular SDU and that the MAC requires instruction about 
whether to accept the channel allocation. In this case the parameter shall be set to "true"; otherwise it 
shall be set to "false". 



Page 334 

ETS 300 392-2: March 1996 

20.2.4.5 Distribution on the 1 8th frame 

In the case of minimum mode, this parameter shall define on which timeslot the MS shall listen to the 
downlink on the frame 18. It may be received by the MS at subscription or at registration. 

20.2.4.6 Encryption 

This parameter shall define whether the signalling message shall be encrypted by the MAC or not before 
its transmission over the air interface. At the receiving side, it shall define whether the message has been 
encrypted for transmission over the air interface. 

20.2.4.7 Endpoint identifier 

This local identifier shall be used to distinguish between multiple concurrent service instances. At the 
MLE-LLC boundary, the endpoint identifier indicates on which link the message shall be sent from the 
different basic and advanced links. At the LLC-MAC boundary, the endpoint identifier refers to which 
timeslot or timeslots may be used for that service. Its implementation is outside the scope of this ETS. 

20.2.4.8 Energy economy group 

This shall be one of the eight allowed energy economy duty cycles as defined in clause 23. 

20.2.4.9 Energy economy startpoint 

This shall be the absolute frame and multiframe number to which the MS shall listen before entering the 
duty cycle defined by the energy economy group. 

20.2.4.10 FCSflag 

This FCS flag shall be used to indicate to the LLC whether extended error protection shall be applied. 

20.2.4.11 Call release 

This shall indicate call release to the MS-MAC e.g. when a user within a group call wishes to leave that 
group call. 

20.2.4.1 2 Half slot condition 

This shall indicate whether a half traffic slot was received successfully. 

20.2.4.1 3 Half slot content 

This shall define the U-plane information content that is to be carried (or was received) in a half slot in a 
circuit mode transmission. 

20.2.4.1 4 Half slot importance 

This shall define the importance of the U-plane information that is to be carried in the circuit. It is defined 
according to table 258. 



Table 258: Definition of half slot importance 



Half slot importance 


Meaning 


0 


No importance (could be used for discontinuous TX) 


1 


Low 


2 


Medium 


3 


Hiqh 



20.2.4.1 5 Half slot position 

This shall define the position of the U-plane information within the timeslot (i.e. first or second half slot). 
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20.2.4.1 6 Half slot synchronisation 

This shall be a local signal provided by the MS MAC to the U-plane application so that the first half slot 
and second half slot parameters correspond to the first and, respectively, second half slot of the timeslot. 
It is provided for the purpose of this description and does not imply any particular implementation. It 
requires that the application keeps synchronised to the half slot in the MAC transmission. 

20.2.4.1 7 Handle to the request 

This shall be a local identifier which acts as a reference to a specific service request (parent) and its 
children. Its implementation is outside the scope of this ETS. 

20.2.4.1 8 Main address 

The main address shall refer to the ASSI, ISSI, SMI or USSI value as defined in ETS 300 392-1 [11], 
clause 7. It shall consist of the MS source address for the uplink. It shall consist of the destination address 
for the downlink and may therefore include GSSI in addition to the previous addresses. 

20.2.4.1 9 MLE activity indicator 

This indicates whether any of the layer 3 entities are currently active. It may be used by the MS-MAC in its 
energy economy procedure. 

20.2.4.20 New endpoint identifier 

The new endpoint identifier shall refer to the new resource allocation especially to link an additional 
resource allocation to the previous allocation. 

20.2.4.21 Number of timeslots 

The number of timeslots shall be used to define the throughput of a circuit mode service (with the selected 
error protection) or the maximum throughput of a packet mode service. 

20.2.4.22 Operating mode 

The operating mode shall be used for the higher layers (i.e. CMCE) to give instructions to the MS MAC to 
switch between signalling and traffic mode. It may comprise the following indications: 

switch U-plane on/off; 

TX-grant flag; 

simplex/duplex flag; 

type of circuit (i.e. TCH/S, TCH/7,2, TCH/4,8, TCH/2,4); 

interleaving depth N; 

encryption flag; 

call identifier; 

user device; 

endpoint identifier. 

20.2.4.23 Path loss 

Related to the cell selection/re-selection mechanism and based on measurements, the path loss consists 
of two variables that may be calculated. Their definition and the formulas are in clause 23 together with 
the different procedures. 
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20.2.4.24 PDU priority 

This priority field shall be used within the LLC and MAC local to one MS. It shall not be transported to the 
peer entity. It may be used in the LLC to define the sending order of TL-SDU. It shall be used in the MAC 
as the priority in the random access protocol. The number of supported priority levels shall be eight. 
Priorities are defined in clause 23. 

20.2.4.25 Quality indication 

This quality indication may be used to indicate locally what the reception quality is. 

20.2.4.26 Quality of Service (QoS) 

The QoS parameters shall be used to facilitate the negotiation of the quality of service as defined in ETS 
300 392-1 [11]. The quality of service in this model is defined at the DLL as a set of TETRA specific 
parameters. 

NOTE 1 : Most of the parameters and selection of their values are either MS or network 
dependent. 

NOTE 2: TETRA specific parameters may or may not control all aspects of each QoS parameter 
at the network layer SAP. 

Parameter values for the throughput for constant delay services shall be as defined in table 259. 



Table 259: Throughput for constant delay services 



Parameter 


Values 


Remarks 


Transmission rate 


2 400, 4 800 or 7 200 bit/s times the 
Number of timeslots 


TMD-SAP (negotiable) 


Parameter values for the throughput for variable delay sen/ices shall be as defined in table 260. 


Table 260: Throughput for variable delay services 


Parameter 


Values 


Remarks 


Maximum transmission rate 


Number of timeslots 1 to 4 


AL-SETUP PDU (negotiable) 


Mean transmission rate 


See clause 21 for definition 


AL-SETUP PDU (negotiable) 


Maximum length of TL-SDU 


N.251 for basic link and N.271 for 
advanced link 


Predefined or AL-SETUP PDU 
(negotiable) 


TL-SDU window size 


N.272 


AL-SETUP PDU (negotiable) 


The parameters for the residual error rate and residual error probability shall be as defined in table 261. 




Table 261 : Residual error rate 




Parameter 


Values 


Remarks 


The use of FCS 


Included, not included 


Local selection in the basic link 
services 



Parameters for the transfer failure probability shall be as defined in table 262. 



Table 262: Transfer failure probability 



Parameter 


Values 


Remarks 


Maximum number of TL- 
SDU re-transmissions 


N.252 and N.253 for basic link & 
N.273 and N.282 for advanced link 


Predefined or 

AL-SETUP PDU (negotiable) 


Maximum number of 
segment re-transmissions 


N.274 


AL-SETUP PDU (negotiable) 
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Parameters for the NC Release failure probability shall be as defined in table 263. 



Table 263: NC Release failure probability 



Parameter 


Values 


Remarks 


Number of disconnection 
repeats 


N.263 


Predefined 



20.2.4.27 Report 

Report shall generally indicate the progress or failure of information transfer and the cause of it. 

The protocol model uses the report parameters in the protocol description at the A-SAP, C-SAP and 
D-SAP. The A-SAP reports (TLA-SAP and TMA-SAP) are defined in table 264. 

Table 264: Reports at TMA and TLA SAPs 



Report 


SAP 


handle 


1 IVIM, 1 Ln 


service definition 


TLA 


service chanqe 


TLA 


reset 


TLA 


set-up failure 


TLA 


service temporarily not supported 


TLA 


service not supported 


TLA 


rejection 


TLA 


close 


TLA 


incominq disconnection 


TLA 


disconnection failure 


TLA 


local disconnection 


TLA 


first complete transmission 


TLA 


success, successful transfer 


TLA 


failed transfer (e.q. maximum number of re-transmission exceeded) 


TLA 


aborted, SDU not completely sent 


TMA, TLA 


aborted, SDU sent at least once 


TMA, TLA 


layer two transmission activities continuing 


TLA 


first complete transmission by random access 


TMA 


successful complete transmission by random access 


TMA 


complete transmission by stealing or by reserved access 


TMA 


random access failure 


TMA, TLA 


fragmentation failure 


TMA 



NOTE: The report parameter may be used to indicate a cause or a reason and possibly 
position of an error. 

20.2.4.28 Scanning measurement method 

This parameter shall specify which of the several methods of measurement the MAC shall use for the 
scanning process. 

20.2.4.29 SCCH information 

This parameter shall be used in the MAC to calculate which common control channel to use when 
common SCCH are in operation. It may be received by the MS at subscription or at registration. 

20.2.4.30 Scrambling code 

This shall contain the Mobile Network Identity (MNI) as described in ETS 300 392-1 [11], clause 7. It shall 
be given to the scrambling process in the physical layer together with the colour code. 
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20.2.4.31 Set-up report 

This shall be used to report set-up phase, see clause 21 for definition. 

20.2.4.32 Stealing permission 

This parameter shall define whether the MAC may use stealing to send this SDU. Within layer 2 it may 
have the following meanings: 

steal immediately; 

steal within time T.21 4; 

steal when convenient; or 

stealing not required. 

The value "steal within time T.21 4" should be used for the reply to a BS message received while the MS is 
transmitting traffic. 

20.2.4.33 Stealing repeats flag 

This shall be used by the higher layers in the MS to trigger a special stealing method in the MAC (see 
clause 23). This method should only be used for signalling at the end of an uplink traffic transmission (e.g. 
for U-TX-CEASED or possibly U-DISCONNECT). 

20.2.4.34 Stolen indication 

This shall indicate whether or not the information content of a halfslot is stolen for signalling purposes. At 
the transmitting side, this parameter may be used to force signalling mode in the MAC for either the first or 
both half slots within a timeslot to be transmitted. At the receiving side, this parameter shall be available to 
the upper layer to enable correct handling of stolen information. 

20.2.4.35 Subscriber class 

A subscriber class shall define a population subdivision e.g. for random access control. The operator may 
define the values and meaning of each class. The subscriber class information is received by the MS at 
subscription or at registration. If the MS receives subscriber class information at subscription, and then 
also is assigned subscriber class information at registration, then the information at registration shall be 
used. 

The subscriber class parameter as supplied in primitives from layer 3 is a bit mapped field which indicates 
for each class whether the MS belongs to that class. 

20.2.4.36 Threshold level 

Based on measurements as defined in clause 23, this shall be the calculated value of some global 
variable used in MLE in the process of cell selection/re-selection. 

20.2.4.37 Threshold values 

The values shall be thresholds imposed in the MAC by the MLE to take a relevant action (e.g. inform MLE 
using suitable primitive) if some measured and/or calculated MAC parameters exceed these limits. 

20.2.4.38 TL-SDU 

The TL-SDU is the service user data message from the MLE layer. It shall be the MLE PDU including the 
MLE header. It is considered here as a parameter of the service primitive. 

20.2.4.39 TL-SDU length 

The TL-SDU length shall be the number of bits of the TL-SDU. 
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20.2.4.40 TM-SDU 

The TM-SDU is the service user data message from the LLC. It shall be the LLC PDU including the LLC 
header and optional FCS. It is considered here as a parameter of the service primitive. 

20.2.4.41 TM-SDU length 

The TM-SDU length shall be the number of bits of the TM-SDU. 

20.2.4.42 Valid addresses 

Valid addresses are the addresses that the MAC MS shall recognise as the ones attached to the MS. 
20.3 Services provided by LLC 
20.3.1 Services at the TLA-SAP 

The SAP may provide one or more logical channels marked by endpoint identifiers. The service user shall 
select wanted service by using a service request primitive with an endpoint identifier as a parameter. The 
direction of the information flow can be from BS to MS, from MS to BS or both; it can also be local control 
information inside the MS or BS. 

The TLA SAP shall be used for addressed signalling and data transfer. Table 265 shows the relationship 
for one LLC instance. There shall be an individual instance of LLC for each valid address. 



Table 265: Services provided at the TLA-SAP 



Service description for TLA SAP 


Address 


Direction of the 
information flow 


Point-to-point acknowledged 


individual SSI 


Bi-directional 


Point-to-point unacknowledged 


individual SSI 


Bi-directional 


Point-to-multipoint unacknowledged 


group SSI (GSSI) 


Downlink 


Point-to-multipoint with presence indication 


group SSI (GSSI) 


Bi-directional 



NOTE: In this ETS only the BS may initiate the presence indication service. 



Under the TLA-SAP, the LLC shall use the TMA-SAP for transferring the information down to the MAC. 

The LLC may offer basic link (connectionless mode) service and advanced link (connection orientated 
mode) service. Within each of these services both an acknowledged and an unacknowledged data 
transfer is defined in the protocol. These possibilities and normal usage are shown in table 266. 



Table 266: Data transfer relationships available in the LLC 



Service offered 


Acknowledged data transfer 


Unacknowledged data transfer 


Basic Link 


Point-to-point signalling message or 
data transfer 
(short messages) 


Broadcast or point-to-multipoint signalling 
message or data transfer 
(short messages downlink) 


Advanced link 


Point-to-point signalling or data 
transfer (long messages) 


Point-to-multipoint signalling or data transfer 
(long messages downlink) 



Downlink transmissions addressed to an individual MS should, in most cases, use acknowledged service. 
All uplink transmissions with a valid address shall use acknowledged transfer. 



Normal information transfer addressed to a group of MSs shall use unacknowledged transfer on the 
downlink. In the case of presence indication request the BS shall use a kind of acknowledged data 
transfer, with reserved access for the acknowledgement, knowing that if there are multiple responses from 
the MSs in the group, there is a risk of collision that will make the responses un-decodeable. If the 
message can be decoded, the BS will know that there was at least one responding MS. If there are 
collisions, the BS may assume presence of MSs from the measured RSSI on the uplink. How this 
measurement is done is outside the scope of this ETS. 
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The advanced link acknowledged mode may be used in all cases where an acknowledged service is 
required for a point-to-point data transfer. The advanced link may also be used for point-to-multipoint data 
transfer in unacknowledged mode. In this case data transfer normally consists of set-up phase, data 
transfer phase possibly with repetition and selective re-assembly of received data and disconnection 
phase. 

20.3.2 Services at the TLB-SAP 

The TLB-SAP shall be used for un-addressed data transfer as presented in table 267. This includes the 
system information broadcast messages. In the protocol model there are no LLC functions under the 
TLB-SAP and the LLC shall convey information directly to the MAC using the TMB-SAP. 



Table 267: Services provided at the TLB-SAP 



Service description for TLB-SAP 


Address 


Direction 


Point-to-multipoint unacknowledged 


none 


Downlink 



20.3.3 Services at the TLC-SAP 

The TLC-SAP shall be used in this model for all local layer management control, such as scanning control 
and signal quality measurements (see table 268). TLC-SAP does not provide any data transfer service 
over the air interface. 



Table 268: Services provided at the TLC-SAP 



Service description for TLC-SAP 


Address 


Direction 


Local management and control 


None 


Bi-directional within the MS 
protocol stack 



20.3.4 LLC service primitives 

The following tables summarise LLC service primitives. If the service primitive is provided or not provided 
in both the basic and advanced links, then yes and no are used respectively. In other cases the LLC link 
type is mentioned. 



Table 269: TLA-SAP service primitives 



Service primitive 


request 


Indication 


Response 


Confirm 


TL-CANCEL 


yes 


no 


no 


no 


TL-CONNECT 


advanced link 


advanced link 


advanced link 


advanced link 


TL-DATA 


yes 


yes 


basic link 


yes 


TL-DISCONNECT 


advanced link 


advanced link 


no 


advanced link 


TL-RELEASE 


advanced link 


yes 


no 


no 


TL-REPORT 


no 


yes 


no 


no 


TL-UNITDATA 


yes 


yes 


no 


optional 


Table 270: TLB-SAP service primitives 


Service primitive 


request 


Indication 


Response 


Confirm 


TL-SYNC 


yes, BS 


yes, MS 


no 


no 


TL-SYSINFO 


yes, BS 


yes, MS 


no 


no 
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Table 271 : TLC-SAP service primitives 



Service primitive 


Request 


Indication 


Response 


Confirm 


TL-CON FIGURE 


yes 


no 


no 


yes 


TL-MEASUREMENT 


no 


yes 


no 


no 


TL-MONITOR 


no 


yes 


no 


no 


TL-MONITOR-LIST 


yes 


no 


no 


no 


TL-REPORT 


no 


yes 


no 


no 


TL-SCAN 


yes 


no 


no 


yes 


TL-SCAN-REPORT 


no 


yes 


no 


no 


TL-SELECT 


yes 


yes 


yes 


yes 



20.3.5 Service primitive descriptions 

In tables 272 to 290 inclusive, which define parameters for the primitives, the following keys are used: 



M: Mandatory; C: Conditional; (=): Equal to corresponding primitive; -: Not used 
20.3.5.1 Primitives at the TLA-SAP (MLE-LLC) 

20.3.5.1 .1 TL-CANCEL primitive 

A TL-CANCEL request may be used locally for an MS or BS to cancel a previous request. This primitive 
shall not send messages over the air interface. The parameters shall be as defined in table 272. 



Table 272: Parameters used in the TL-CANCEL primitive 



Parameter 


Request 


Handle to the request (see note) 


M 


NOTE: Not sent over the air interface. 



20.3.5.1 .2 TL-CONNECT primitive 

The connection primitives, if required prior to a transfer, shall be used to establish a LLC advanced link. 
The parameters shall be as defined in table 273. 

TL-CONNECT request shall be used by the layer 2 service user to initiate the establishment of advanced 
link with a certain quality of service. It may also reset the established link. 

TL-CONNECT indication shall be used by the Layer 2 to inform the Layer 2 service users that the 
establishment of an advanced link with a certain quality of service or the reset of the current advanced link 
has been requested. 

TL-CONNECT response shall be used by the layer 2 service users to accept the establishment or the 
reset of the advanced link with a certain quality of service. According to the available resources, the value 
of the service parameters may be modified (lower grade of service) in the response. In such a case, the 
advanced link characteristics will match these new features. 

TL-CONNECT confirm shall be used by the layer 2 to inform the Layer 2 service users that the 
establishment or re-establishment (reset) of the advanced link has been completed with a certain quality 
of service as indicated in the request primitive. 
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Table 273: Parameters used in the TL-CONNECT primitive 



Parameter 


Request 


Indication 


Response 


Confirm 


Address type 


M 


(=) 


M 


(=) 


Main address 


M 


(=) 


M 


(=) 


Scrambling code (see note) 


M 


(=) 


M 


(=) 


Endpoint identifier (see note) 


C 


M 


M 


M 


New endpoint identifier (see note) 




C 




C 


PDU priority (see note) 


M 




M 




Stealing permission (see note) 


M 




M 




Subscriber class (see note) 


M 




M 




Quality of Service 


M 


(=) 


M 


(=) 


Encryption 


M 


(=) 


M 


(=) 


Channel change response required 




M 




M 


Set-up report 


M 


(=) 


M 


(=) 


NOTE: Not sent over the air interface. 



20.3.5.1 .3 TL-DATA primitive for the advanced link 



Parameters in acknowledged advanced link service for the following primitives shall be as defined in 
table 274. 

TL-DATA request shall be used by the layer 2 service user to request transmission of a TL-SDU. 

TL-DATA indication shall be used by the Layer 2 to deliver the received TL-SDU to the Layer 2 service 
user. 

TL-DATA confirm shall be used by the layer 2 to inform the layer 2 service user that it has completed 
successfully the transmission of the requested TL-SDU. 



Table 274: Parameters used in the TL-DATA primitive for advanced link 



Parameter 


Request 


Indication 


Confirm 


Address type 


M 


(=) 


(=) 


Main address 


M 


(=) 


(=) 


Endpoint identifier (see note) 


M 


M 


M 


New endpoint identifier (see note) 




C 


C 


TL-SDU 


M 


(=) 




TL-SDU length (see note) 


M 






Scrambling code 


M 


(=) 


(=) 


PDU priority (see note) 


M 






Stealing permission (see note) 


M 






Subscriber class (see note) 


M 






Encryption 


M 


(=) 


(=) 


Channel change response required 




M 




Report 






M 


NOTE: Not sent over the air interface. 



20.3.5.1 .4 TL-DATA primitive for the basic link 

In the acknowledged basic link data transfer service the parameters for the following primitives shall be as 
defined in table 275. 

TL-DATA request shall be used by the layer 2 service user to request transmission of a TL-SDU. The 
TL-SDU will be acknowledged by the peer entity. 

TL-DATA indication shall be used by the Layer 2 to deliver the received TL-SDU to the Layer 2 service 
user. 
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TL-DATA response shall be used by the layer 2 service user to respond to the previous TL-DATA 
indication. The TL-DATA response may contain a TL-SDU. That TL-SDU will be sent without an explicit 
acknowledgement from the peer entity. 

TL-DATA confirm shall be used by the layer 2 to inform the layer 2 service user that it has completed the 
transmission of the requested TL-SDU. Depending on the availability of the response at the peer entity 
before transmission of the acknowledgement, the confirm may or may not carry a TL-SDU. 



Table 275: Parameters used in the TL-DATA primitive for basic link 



Parameter 


Request 


Indication 


Response 


Confirm 


Address type 


M 


(=) 


M 


(=) 


Main address 


M 


(=) 


M 


(=) 


Endpoint identifier (see note) 


C 


c 


C 


C 


New endpoint identifier (see note) 




c 




C 


TL-SDU 


M 


(=) 


M 


C(=) 


TL-SDU length (see note) 


M 




M 




Scrambling code 


M 


(=) 


M 


(=) 


PDU priority (see note) 


M 




M 




Stealing permission (see note) 


M 




M 




Subscriber class (see note) 


M 




M 




FCS flag 


M 


(=) 


M 


(=) 


Encryption 


M 


(=) 


M 


(=) 


Stealing repeats flag (see note) 


C 




C 




Channel change response required 




M 




M 


Report 








M 


NOTE: Not sent over the air interface. 



20.3.5.1 .5 TL-DISCONNECT primitive 



The disconnection primitives shall be used to disconnect a LLC advanced link. The parameters shall be 
as defined in table 276. 



Table 276: Parameters used in the TL-DISCONNECT primitive 



Parameter 


Request 


Indication 


Confirm 


Address type 


M 


(=) 


(=0 


Main address 


M 


(=) 


(=> 


Endpoint identifier (see note) 


M 


M 


M 


New endpoint identifier (see note) 




C 


C 


Scrambling code 


M 


(=) 


(=) 


PDU priority (see note) 


M 






Stealing permission (see note) 


M 






Subscriber class (see note) 


M 






Encryption 


M 


(=) 


(=) 


Channel change response required 




M 




Report 


M 


(=) 


(=) 


NOTE: Not sent over the air interface. 
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20.3.5.1 .6 TL-RELEASE primitive 

The release primitive shall be used to disconnect a LLC advanced link, when a disconnection is 
recognised by the service user and LLC might no longer perform a disconnection with the peer entity. The 
parameters in this primitive shall be as defined in table 277. 



Table 277: Parameters used in the TL-RELEASE primitive 



Parameter 


Request 


Indication 


Address type (see note) 


M 


M 


Main address (see note) 


M 


M 


Endpoint identifier (see note) 


M 


M 


NOTE: Not sent over the air interface. 



20.3.5.1 .7 TL-REPORT primitive (TLA-SAP) 

TL-REPORT indication shall be used by the layer 2 to report to the layer 2 service user the progress or 
failure of a request procedure. The progress indication shall be passed as the Report parameter. This 
primitive may be issued to the layer 2 service user as an indication that an unrecoverable error has 
occurred. 

Parameters for this primitive shall be as defined in table 278. 

NOTE: The completion of the requested service is indicated by the same primitive name with 
the type confirm. 

Table 278: Parameters used in the TL-REPORT primitive (TLA-SAP) 



Parameter 


Indication 


Handle to the request (see note) 


M 


Report (see note) 


M 


NOTE: Not sent over the air interface. 



20.3.5.1 .8 TL-UNITDATA primitive 

In the unacknowledged data transfer service the parameters for the following primitives shall be as 
defined in table 279 for the basic link and as defined in table 280 for the advanced link. 

TL-UNITDATA request shall be used by the layer 2 service user to request layer 2 to transmit a TL-SDU. 

TL-UNITDATA indication shall be used to deliver the received TL-SDU to the layer 2 service user. 

TL-UNITDATA confirm may be used to indicate completion of sending of the requested TL-SDU. 
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Table 279: Parameters used in the TL-UNITDATA primitive in basic link 



Parameter 


Request 


Indication 


Confirm 

(note 2) 


Address type 


M 


(=) 


(=) 


Main address 


M 


(=) 


(=) 


Endpoint identifier (note 1) 


C 


(=) 


(=) 


New endpoint identifier (note 1) 


- 


C 


- 


TL-SDU 


M 


M 


- 


TL-SDU length (note 1) 


M 




- 


Scrambling code 


M 


M 




PDU priority (notel) 


M 






Stealing permission (note 1) 


M 






Subscriber class (note 1) 


M 






FCS flag 


M 


(=) 




Encryption 


M 


(=) 




Channel change response reguired 




M 




Report 




C 


C 


NOTE 1 : Not sent over the air interface. 

NOTE 2: In this case, the confirm is a local knowledge of the sending entity. 


Table 280: Parameters used in the TL-UNITDATA primitive in advanced link 


Parameter 


Request 


Indication 


Confirm 

(note 2) 


Address type 


M 


(=) 


(=) 


Main address 


M 


(=) 


(=) 


Endpoint identifier (note 1) 


C 


(=) 


(=) 


New endpoint identifier (note 1) 




C 




TL-SDU 


M 


(=) 




TL-SDU length (notel) 


M 






Scrambling code 


M 


M 




PDU priority (notel) 


M 






Stealing permission (note) 


M 






Subscriber class (note 1) 


M 






Encryption 


M 


(=) 




Channel change response required 




M 




Report 




C 


C 


NOTE 1 : Not sent over the air interface. 

NOTE 2: In this case, the confirm is a local knowledge of the sending entity. 



20.3.5.2 Signals at the TLA-SAP (WILE-LLC) 

The TLA-SAP signals (FLOW-READY signal and FLOW-NOT-READY signal) are used in the protocol 
description of the MS's message-buffering interface between the LLC service user (MLE) and LLC. As this 
is purely local to an MS, the following description is provided for information only. 

The FLOW-READY signal shall be used by the LLC service user in the MS to indicate to the LLC when it 
is capable of receiving more user data TL-SDUs in TL-DATA indication primitives. 

The FLOW-NOT-READY signal shall be used by the LLC service user in the MS to indicate to the LLC 
when it is not capable of receiving more user data TL-SDUs in TL-DATA indication primitives. 

NOTE: The validity time of one FLOW-NOT-READY signal at the LLC is limited by T.271 and 
T.272 in the sending and receiving entities respectively. 
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The parameters in the flow control signal shall be: 

address type; 

main address; and 

endpoint identifier. 
The endpoint identifier will not be sent over the air. 
20.3.5.3 Primitives at the TLB-SAP (MLE-LLC) 

In this ETS the LLC layer does not have any TMB-SAP related functions. The requests at the TLB-SAP 
are directly mapped as requests at the TMB-SAP and the indications at the TMB-SAP are directly 
transported to TLB-SAP indications. 

20.3.5.3.1 TL-SYNC primitive 

The request primitive shall be used in the BS to broadcast synchronisation information. The indication 
primitive shall be used in the MS to transport the received TM-SDU part of the synchronisation information 
via LLC to MLE. The BS MAC will broadcast the information at suitable intervals. Every new request may 
change the content of the broadcast information. The parameters shall be as defined in table 281 . 



Table 281 : Parameters used in the TL-SYNC primitive 



Parameter 


Request 


Indication 


Channel 


M 


M 


TL-SDU 


M 


M 


TL-SDU length 


M 


M 


Priority (not sent over the air interface) 


M 





20.3.5.3.2 TL-SYSINFO primitive 

The request primitive shall be used in BS to broadcast system related information needed in the process 
of cell selection on the BNCH. The indication primitive shall be used in MS to transport the received 
TM-SDU via LLC to MLE. The BS MAC will broadcast the information at suitable intervals. Every new 
request may change the content of the broadcast information. The parameters shall be as defined in 
table 282. 



Table 282: Parameters used in the TL-SYSINFO primitive 



Parameter 


Request 


Indication 


Channel 


M 


M 


TL-SDU 


M 


M 


TL-SDU length 


M 


M 


Priority (Not sent over the air interface) 


M 





20.3.5.4 Primitives at the TLC-SAP (MLE-LLC) 

In this ETS the LLC layer does not have any TLC-SAP related functions. The requests and responses at 
the TLC-SAP are directly mapped as requests and responses at the TMC-SAP and the indications and 
confirms at the TMC-SAP are directly transported to TLC-SAP indications and confirms. 
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20.3.5.4.1 TL-CONFIGURE primitive 

TL-CONFIGURE request, confirm: this shall be used to set-up and configure the layer 2 according to the 
chosen cell parameters and the current state of the MS. The parameters shall be as defined in table 283. 



Table 283: Parameters used in the TL-CONFIGURE primitive 



Parameter 


Request 
(see note) 


Confirm 
(see note) 


Threshold values 


C 


(=) 


Distribution on 18th frame 


C 


(=) 


SCCH information 


C 


(=) 


Energy economy group 


C 


(=) 


Energy economy startpoint 


C 


(=) 


MLE activity indicator 


C 




Channel change accepted 


C 




Operating mode 


C 


(=) 


Call release 


C 


(=) 


Valid addresses 


C 


(=) 


NOTE: Not sent over the air interface. 



20.3.5.4.2 TL-M E ASU R EM E NT primitive 

TL-MEASUREMENT indication: this shall be used to indicate to the upper layer the quality of the link of 
the current serving cell, based on the weighted result of the measured and acquired parameters. The 
parameters shall be as defined in table 284. 



Table 284: Parameters used in the TL-MEASUREMENT primitive 



Parameter 


Indication (see note) 


Channel 


M 


Path loss C1 


M 


Quality indication 


C 


NOTE: Not sent over the air interface. 



20.3.5.4.3 TL-MONITOR primitive 

TL-MONITOR indication: this shall be used at the TLC-SAP to indicate the result of the monitoring of one 
particular channel. This shall be a consequence of the action started by TL-MONITOR-LIST request. The 
parameters shall be as defined in table 285. 



Table 285: Parameters used in the TL-MONITOR primitive 



Parameter 


Indication (see note) 


Channel 


M 


Path loss C2 


M 


Quality indication 


C 


NOTE: Not sent over the air interface. 
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20.3.5.4.4 TL-MONITOR-LIST primitive 

TL-MONITOR-LIST request: this shall be used at the TLC-SAP to start the monitoring of a list of 
channels given as parameters. The parameters shall be as defined in table 286. 



Table 286: Parameters used in the TL-MONITOR-LIST primitive 



Parameter 


Request (see notel) 


Channel 


M 


Channel (see note 2) 


C 


NOTE 1 : Not sent over the air interface. 
NOTE 2: May be repeated. 



20.3.5.4.5 TL-REPORT primitive (TLC-SAP) 

TL-REPORT indication: this shall be used to report locally to MLE about the status of an action 
undertaken at the reception of a request. It may also be used to report usage marker mismatch, downlink 
failure, uplink failure or when the maximum path delay has been exceeded. The parameters shall be as 
defined in table 287. 



Table 287: Parameters used in the TL-REPORT primitive (TLC-SAP) 



Parameter 


Indication (see note) 


Handle to the request 


C 


Report 


M 


NOTE: Not sent over the air interface. 



20.3.5.4.6 TL-SCAN primitive 

TL-SCAN request, confirm: this shall be used at the TLC-SAP to start the scanning of a defined channel 
given as a parameter, together with the type of scanning (interrupting or not). The parameters shall be as 
defined in table 288. 



Table 288: Parameters used in the TL-SCAN primitive 



Parameter 


Request 
(see note) 


Confirm 
(see note) 


Channel 


M 


(=) 


Scanning measurement method 


M 


(=) 


Threshold level 


C 


M 


Report 




M 


NOTE: Not sent over the air interface. 



20.3.5.4.7 TL-SCAN-REPORT primitive 

TL-SCAN-REPORT indication: this shall be used at the TLC-SAP to report locally the updated 
measurement of the path loss parameter after scanning has been completed. It shall be based on the 
updated signal strength measurements. The parameters shall be as defined in table 289. 



Table 289: Parameters used in the TL-SCAN-REPORT primitive 



Parameter 


Indication 


Channel (see note) 


M 


Threshold level (path loss C1 ) (see note) 


M 


Report (see note) 


C 


NOTE: Not sent over the air interface. 
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20.3.5.4.8 TL-SELECT primitive 

TL-SELECT request, indication, response, confirm: this shall be used at the TLC-SAP to choose the 
channel onto which the radio will have to tune. The request and confirm shall be used when the MLE 
instructs the MAC to change channel. The indication shall be used by the MAC to inform the MLE of a 
channel change under the control of the BS. The response shall be used for a cell change. The 
parameters shall be as defined in table 290. 



Table 290: Parameters used in the TL-SELECT primitive 



Parameter 


Request 


indication 


Response 


Confirm 


Channel (see note) 


M 


M 


(=) 


(=) 


Threshold level (see note) 


C 


M 


c 


M 


Main carrier number 


C 




c 


C 


Report (see note) 




C 


c 


C 


NOTE: Not sent over the air interface. 



NOTE: The main carrier number is generally only used for announced type 1 cell re-selection 
when a channel change directs the MS to a traffic channel on a new cell. On receiving 
TMC-SELECT indication, the MLE returns TMC-SELECT response indicating the main 
carrier of the new cell and enabling the MAC to reference the SYNC/SYSINFO 
information received when it previously scanned that main carrier. 



20.3.6 State diagram for the basic link 

The state transition diagram in figure 91 applies to the basic link services. 

TL-DATA indication 
TL-DATA response f \ 
TL-UNITDATA indication^ \ 
TL-REPORT indication -tys 

( IDLE ] 

TL-REPORT indication 
TL-DATA confirm 
TL-UNITDATA confirm 



TL-REPORT indication 
TL-DATA request (high priority) 



TL-DATA request 
TL-UNITDATA request 
TL-REPORT indication 




Figure 91 : State transition diagram in basic link at TL-SAP 
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20.3.7 State diagram for advanced link 

The state transition diagram in figure 92 applies to the advanced link. 

TL-DISCONNECT request 



TL-UNITDATA 
indication 



F DISCONNECT! "^-DISCONNECT confirm 
JTL-REPORT indication 



TL-CONNECT 
indication 




xi rnMMCPT^r,(;m\ \ 7 x TL-CONNECT response 

TL-CONNECT confirm\ \ / / (no parameter change) 

— w TL-DATA indication 

s TL-DATA confirm 

TL-DATA request 
TL-REPORT indication 

Figure 92: State transition in connection mode at MLE-LLC SAP (advanced link) 
20.4 Services provided by the MAC 

The MAC shall provide services to higher layers in the protocol architecture via four SAPs. These are 
TMA-SAP, TMB-SAP, TMC-SAP and TMD-SAP. The first three correspond to the TLA-SAP, TLB-SAP 
and TLC-SAP in the LLC. TMD-SAP shall be used for transfer of user information in circuit mode. The 
MAC layer service primitives shall be as listed in tables 291 to 294 inclusive. 

NOTE: The following description refers to the protocol definition, but does not imply any 
implementation. The LLC-MAC boundary and TMD-SAP are internal layer boundaries 
defined to clarify the protocol description. They are not testable boundaries. 

Table 291 : TMA-SAP service primitives 



Service primitive 


Request 


Indication 


Response 


Confirm 


TMA-CANCEL 


yes 


no 


no 


no 


TMA-RELEASE 


no 


yes 


no 


no 


TMA-REPORT 


no 


yes 


no 


no 


TMA-UNITDATA 


yes 


yes 


no 


no 


Table 292: TMB-SAP service primitives 


Service primitive 


request 


Indication 


Response 


Confirm 


TMB-SYNC 


yes, BS 


yes, MS 


no 


no 


TMB-SYSINFO 


yes. BS 


yes, MS 


no 


no 
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Table 293: TMC-SAP service primitives 



Service primitive 


request 


Indication 


Response 


Confirm 


TMC-CONFIGURE 


yes 


no 


no 


yes 


TMC-MEASUREMENT 


no 


yes 


no 


no 


TMC-MONITOR 


no 


yes 


no 


no 


TMC-MONITOR-LIST 


yes 


no 


no 


no 


TMC-REPORT 


no 


yes 


no 


no 


TMC-SCAN 


yes 


no 


no 


yes 


TMC-SCAN-REPORT 


no 


yes 


no 


no 


TMC-SELECT 


yes 


yes 


yes 


yes 


Table 294: TMD-SAP service primitives 


Service primitive 


request 


Indication 


Response 


Confirm 


TMD-REPORT 


no 


yes 


no 


no 


TMD-UNITDATA 


yes 


yes 


no 


no 



20.4.1 Services at the TMA-SAP 



The TMA-SAP shall be used for transfer of signalling and packet data information on the air interface. The 
TMA-SAP provides the following services to the LLC layer: 

data manipulation (PDU composition/decomposition); 

transfer of PDUs as indicated in the following subclauses. 
20.4.1 .1 Service primitives at the TMA-SAP 

20.4.1 .1 .1 TMA-CANCEL primitive 

TMA-CANCEL request: this shall be used to cancel a TMA-UNITDATA request that was submitted by the 
LLC. The parameters shall be as defined in table 295. 



Table 295: Parameters used in the TMA-CANCEL primitive 



Parameter 


Request (see note) 


Handle to the request 


M 


NOTE: Not sent over the air interface. 



20.4.1 .1 .2 TMA-RELEASE primitive 

The release primitive may be used when the MAC leaves a channel so that any advanced links on that 
channel are implicitly disconnected. The parameters in this primitive shall be as defined in table 296. 



Table 296: Parameters used in the TMA-RELEASE primitive 



Parameter 


Indication 


Endpoint identifier (see note) 


M 


NOTE: Not sent over the air interface. 
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20.4.1 .1 .3 TMA-REPORT primitive 

TMA-REPORT indication shall be used by the MAC to report on the progress or failure of a request 
procedure. The result of the transfer shall be passed as a report parameter. The parameters shall be as 
defined in table 297. 



Table 297: Parameters used in the TMA-REPORT primitive 



Parameter 


Indication (see note) 


Handle to the request 


M 


Report 


M 


NOTE: Not sent over the air interface. 



20.4.1 .1 .4 TM A-UNITDATA primitive 

TMA-UNITDATA request shall be used to request MAC to transmit a TM-SDU. 
TMA-UNITDATA indication shall be used by MAC to deliver the received TM-SDU. 
The parameters shall be as defined in table 298. 



Table 298: Parameters used in the TMA-UNITDATA primitive 



Parameter 


Request 


Indication 


TM-SDU 


M 


(=) 


TM-SDU length 


M 




Main address 


M 


(=) 


Address Type 


M 


(=) 


Scrambling code 


M 


(=> 


Endpoint identifier (see note) 


C 


M 


New endpoint identifier (see note) 




C 


PDU priority (see note) 


M 




Stealing permission (see note) 


M 




Subscriber Class (see note) 


M 




Encryption 


M 


(=) 


Stealing repeats flag (see note) 


C 




Channel change response required 




M 


NOTE: Not sent over the air interface. 



20.4.1 .2 Signals at the TMA-SAP 

The TMA-SAP signals (DATA-IN-BUFFER signal and MAC-READY signal) are used in the protocol 
description of the MS's message-buffering interface between LLC and MAC. As this is purely local to an 
MS, the following description is only informative. 

The DATA-IN-BUFFER signal is used by the LLC in the MS to indicate to the MAC when it has signalling 
messages to send, and to indicate the amount of data outstanding. 

The parameters in the DATA-IN-BUFFER signal are as follows: 

a) amount of data in LLC buffer: 

this is the total amount of outstanding individually addressed data to be sent (on the channel 
corresponding to the specified endpoint identifier), and not yet given to the MAC; 

this is the total amount of individually addressed data for both basic link and advanced link 
messages, including acknowledgements; 
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b) priority of highest priority message, and highest stealing permission: 

this is the highest PDU priority and stealing permission parameter for messages in the LLC 
message buffer (for the specified endpoint identifier); 

c) endpoint identifier. 

The MAC-READY signal is issued by the MAC in the MS to the LLC when the MAC is ready to send a 
MAC block. Then the LLC will usually issue a TMA-UNITDATA request primitive to the MAC, containing a 
TM-SDU to be sent in the MAC block. 

The parameters in the MAC-READY signal are as follows: 

a) size of TM-SDU in this MAC block: 

this is the maximum size of TM-SDU that can be carried in the current MAC block (i.e. the 
maximum size without requiring fragmentation); 

b) maximum size of TM-SDU: 

this is the maximum size of TM-SDU that can be handled in the MAC at this time (e.g. the 
maximum size of fragmented TM-SDU); 

c) endpoint identifier. 

20.4.1 .3 Mapping of the service primitives between LLC and MAC under the TxA-SAP 

The LLC shall control the relationships between the LLC data transfer service primitives offered to the 
MLE and the data transfer service primitives offered by the MAC to the LLC. Table 299 shows these 
relationships at the TLA-SAP (MLE-LLC) and the TMA-SAP (LLC-MAC). 



Table 299: Correspondence between MAC and LLC at the TMA-SAP and TLA-SAP 



LLC Service Primitives (TLA-SAP) 


MAC Service Primitive (TMA-SAP) 


TL-CONNECT request 
TL-CONNECT response 
TL-DATA request 
TL-DATA response 
TL-DISCONNECT request 
TL-UNITDATA request 


TMA-UNITDATA request 


TL-CONNECT indication 
TL-CONNECT confirm 
TL-DATA indication 
TL-DATA confirm 
TL-DISCONNECT indication 
TL-DISCONNECT confirm 
TL-UNITDATA indication 


TMA-UNITDATA indication 


TL-CANCEL request 


TMA-CANCEL request 


TL-RELEASE indication 


TMA-RELEASE indication 


TL-RELEASE request 


none 


TL-REPORT indication 


TMA-UNITDATA indication or TMA- 
REPORT indication or not applicable 


NOTE 1 : All the service primitives at the TMA-SAP use signalling channels 
(SCH or STCH), except for the local primitives (CANCEL, RELEASE, 
REPORT). 

NOTE 2: A TL-REPORT may be generated in the LLC without a report from the 
lower layer. 



Page 354 

ETS 300 392-2: March 1996 

20.4.2 Service provided at the TMB-SAP 

The TMB-SAP shall be used for the transfer of un-addressed system broadcast messages, which carry 
network or system organisation information from the BS to the MS. 

In this ETS the LLC layer does not have any TMB-SAP related functions. The requests at the TLB-SAP 
are directly mapped as requests at the TMB-SAP and the indications at the TMB-SAP are directly 
transported to TLB-SAP indications. The service descriptions for the TLB-SAP are therefore valid for the 
TMB-SAP and are not repeated. 

Table 300 shows these relationships at the TLB-SAP (MLE-LLC) and the TMB-SAP (LLC-MAC). 



Table 300: Correspondence between MAC and LLC at the TMB-SAP and TLB-SAP 



LLC Service Primitives (TLB-SAP) 


MAC Service Primitive (TMB-SAP) 


MAC Logical Channel 
(TMV-SAP) 


TL-SYNC request, indication 


TMB-SYNC request, indication 


BSCH 


TL-SYSINFO request, indication 


TMB-SYSINFO request, indication 


BNCH (SCH/HD) 


NOTE: The received system synchronisation and information messages in the MS are 
conveyed to the MLE via the LLC using the TxB-SAP. Parameters calculated when 
receivinq broadcast information are conveyed using the TxC-SAP. 



20.4.3 Service provided at the TMC-SAP 

The TMC-SAP shall be used for the transfer of local layer management information. It does not provide 
data transfer services over the air interface. In this version of ETS the LLC layer does not have any 
TMC-SAP related functions. The requests and responses at the TLC-SAP shall be directly mapped as 
requests and responses at the TMC-SAP and the indications and confirms at the TMC-SAP shall be 
directly transported to the TLC-SAP as indications and confirms. The service descriptions for the 
TLC-SAP are therefore valid for the TMC-SAP and are not repeated. 

Table 301 shows these relationships at the TLC-SAP (MLE-LLC) and the TMC-SAP (LLC-MAC). 



Table 301 : Correspondence between MAC and LLC at the TMC-SAP and TLC-SAP 



LLC service primitives (TLC-SAP) 


MAC service primitive (TMC-SAP) 


TL-CONFIGURE 


TMC-CONFIGURE 


TL-MEASUREMENT 


TMC-MEASUREMENT 


TL-MONITOR 


TMC-MONITOR 


TL-MONITOR-LIST 


TMC-MONITOR-LIST 


TL-REPORT 


TMC-REPORT 


TL-SCAN 


TMC-SCAN 


TL-SCAN-REPORT 


TMC-SCAN-REPORT 


TL-SELECT 


TMC-SELECT 



20.4.4 Service provided at the TMD-SAP 

The TMD-SAP shall be used in the MS in circuit mode for the transfer of speech frames and/or 
synchronisation information for encryption purpose, and/or the transfer of data. It shall provide the 
interface between the MAC and the TETRA speech CODEC, and between the MAC and the other circuit 
mode applications. 

The speech frames may contain either clear or encrypted speech, but their actual information content, as 
the one of data transported in circuit mode, is irrelevant to the MAC. Speech frames may be stolen by the 
MAC according to the parameter definition and the procedures as explained in clause 23. The same 
parameters may be used for circuit mode data. 

Before transmission, speech frames and user data shall be coded and protected in the MAC in a way 
depending on whether they contain only speech or user data related information, one stolen half slot or 
two stolen half slots. Stolen half slots shall contain signalling information, either from C-plane or from U- 
plane (e.g. for encryption synchronisation). 
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For the purpose of the description in the rest of this subclause, the stolen capacity shall be a half slot and 
the unit of exchange at this TMD-SAP shall always be a half slot. Under normal circumstances in traffic 
mode, two primitive exchanges containing each the equivalent of half a slot capacity shall be required to 
fill the physical MAC block going to be transmitted over the air interface. 

20.4.4.1 Service primitives and parameters at the TMD-SAP 

20.4.4.1 .1 TMD-REPORT primitive 

TMD-REPORT indication shall be used by the MAC to report on the progress of a request procedure. For 
example, it shall be used by the sending MAC to report to the U-plane application when the MAC has 
stolen traffic capacity. 

The half slot synchronisation shall be a parameter (or any signal) that the MS MAC shall give internally to 
the U-plane application to enable a distinction between the first and the second half slot, i.e. a proper use 
of first half slot and second half parameters by the U-plane application. For the purpose of this description, 
a TMD-REPORT indication shall be sent before any TMD-UNITDATA request as an initial synchronisation 
for the U-plane application. 

The parameters shall be as defined in table 302. 



Table 302: Parameters used in the TMD-REPORT primitive 



Parameter 


Indication (see note) 


Half slot synchronisation 


C 


TCH type & interleaving depth 


C 


number of slots per TDMA frame 


C 


encryption on/off flag 


C 


call identifier 


C 


user device 


C 


Report 


M 


NOTE: Not sent over the air interface. 



20.4.4.1 .2 TMD-UNITDATA primitive 

TMD-UNITDATA request shall be used to request MAC to transmit one half slot. 
TMD-UNITDATA indication shall be used by MAC to deliver one half slot. 
The parameters shall be as defined in table 303. 



Table 303: Parameters used in the TMD-UNITDATA primitive 



Parameter 


Request 


Indication 


Half slot content 


M 


M 


Half slot position (see note) 


C 


C 


Half slot importance (see note) 


M 




Stolen indication 


M 


M 


Half slot condition (see note) 




M 


User device (see note) 


C 


C 


NOTE: Not sent over the air interface. 



NOTE: The half slot position may be implicit after the first synchronisation phase. 
The user device number shall identify the circuit which the information shall be transferred to, and from. 
21 Layer 2 PDU description 

This clause describes the PDUs for the V+D air interface at layer 2. An overview of the DLL architecture 
can be found in clause 19. The sub-layer interactions between MAC and LLC are described herein by the 
protocol elements. 
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This clause is intended to be read together with the MAC protocol clause 23 and LLC protocol clause 22. 
A detailed service description is provided in clause 20. 

Binary values are indicated in this clause by a subscript 2, thus: 101 IO2. 



21.1 DLL PDU structure 



21.1.1 DLL overhead 



The DLL overhead contains independent LLC and MAC headers. Therefore, the following description 
distinguishes first LLC overhead and then MAC overhead. Overhead shall be added by a sub-layer 
independently of the overhead attached by the other sub-layer. 



21 .1 .2 LLC PDUs structure 



The LLC adds a LLC header to TL-SDUs to create LLC PDUs. The LLC PDU shall have the format 
illustrated in figure 93. 



MLE 


TL-SDU 








LLC 






LLC header 


TL-SDU 


LLC FCS 



Figure 93: Construction of an LLC PDU (shown with optional FCS) 

21.1.2.1 LLC header 

The LLC header discriminates between various PDUs, see table 304. The uses of the different LLC PDUs 
are specified in clause 22. 

21 .1 .2.2 Format of LLC header 

The LLC PDU type illustrated in figure 94 is defined in subclause 21.2.1. The LLC PDU type element shall 
have a length of 4 bits. The length of the LLC information structure depends on the PDU type. 



LLC header 



LLC PDU type LLC information 



TL-SDU 



Figure 94: General format of a LLC header before the TL-SDU content 



21.1.2.3 LLC FCS 



For the advanced link and on request for the basic link, the LLC shall calculate and add a FCS to the 
information being transmitted. Its size shall be 32 bits. This provides a Probability of Undetected 
Erroneous Message (PUEM) of about 10" 13 or better. This may be requested for packet data transmission 
whereas the MAC error detection mechanism (16 bits CRC) guarantees a PUEM of 10" 6 only. The LLC 
FCS shall be placed immediately after the end of the TL-SDU as shown in figure 93. The FCS as defined 
in clause 22 shall be used. 
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21 .1 .3 MAC PDUs structure 
21.1.3.1 MAC overhead 

Each TM-SDU to be transmitted shall have a MAC header added as shown in figure 95. 

LLC 



MAC 



TM-SDU 



MAC Header 



TM-SDU 



21.1.3.2 



Figure 95: General format of the MAC PDU 
Format of the MAC header 



The MAC header enables the receiving MAC entity to identify the functions to be performed on the MAC 
PDU. The MAC type defines the structure of the MAC information. The MAC header shall have the format 
shown in figure 96. 



MAC header 



MAC type 



MAC address and MAC information 



TM-SDU 



Figure 96: General format of a MAC header 

Generally, the MAC header shall contain three types of element, the MAC type, the MAC address and 
some MAC information. In order to keep the overhead as small as possible, continuations and the end of 
fragmented data (MAC-FRAG and MAC-END) shall not contain any address. 

The MAC header structure enables the MAC to associate and transmit several independent MAC PDU in 
one MAC block. Unused bits should be filled with a NULL PDU as illustrated in figure 97, or fill bits may be 
used (not shown) (see clause 23). 



MAC Header 1 


TM-SDU 1 


MAC Header 2 


TM-SDU 2 




NULL PDU 



21.1.3.2.1 



Figure 97: Association of several MAC PDU in one MAC block 
MAC type 



The MAC type enables to distinguish between the different PDU and the different SAP to which the 
receiving MAC should route the TM-SDU. 



21.1.3.2.2 



MAC information 



According to the MAC type, the location and format of MAC address and information is defined in the 
relevant MAC section. 

21 .1 .3.2.3 MAC address 

For the layer 2 addressing particularities, refer to ETS 300 392-1 [11], clause 7, and clause 23 of this ETS. 
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21.1.4 DLL PDU building 



21 .1 .4.1 Basic link illustration 



Figure 98 illustrates the method when a message (MAC header and TM-SDU) fits within the MAC block 
size. 



LLC header 



TL-SDU 



MAC header 



TM-SDU 



Figure 98: Building of DLL PDU (with no fragmentation) 

If the size of the TM-SDU exceeds the available capacity in a MAC block, MAC fragmentation shall occur 
as shown in figure 99. 



LLC header 



TL-SDU 



TM-SDU 



MAC header 



TM-SDU (start) 



MAC header 



TM-SDU (cont.) 



MAC header TM-SDU (end) 



Figure 99: MAC fragmentation of a long TM-SDU 

Optionally, the LLC may add a FCS as part of the TM-SDU (This is not shown in figures 98 and 99, but is 
illustrated on figure 93). The whole TM-SDU contains only a single LLC header. Therefore, if an error 
occurs during transmission, the whole TM-SDU has to be re-transmitted. This is not the case for the 
advanced link illustrated in figure 100. 



21 .1 .4.2 Advanced link illustration 



TL-SDU 



FCS 



LLC header 



Segment LLC header Segment LLC header Segment 



MAC header 



TM-SDU 



MAC header 



TM-SDU 



MAC header 



TM-SDU 



Figure 100: Segmentation provided by the advanced link 

As opposed to fragmentation performed by the MAC, LLC segmentation shall label each segment with a 
sent segment sequence number S(S) so that each of the segments shall be uniquely identified and used 
as the re-transmission unit (selective rejection applies under the advanced link, refer to clause 22). Figure 
100 shows that each TM-SDU has its own LLC header in addition to the MAC header. The LLC shall add 
a FCS at the end of the last segment. This FCS shall be calculated over the entire TL-SDU. 
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21 .1 .5 PDU description format 

The following subclauses contain descriptions of the LLC and MAC protocol PDUs and the information 
elements contained in the PDUs. The structure of the PDU definitions represented by the tables is as 
follows: 

the information element column is the name of the element; 

the element length column defines the length of the element in bits; 

the element types (C/O/M) are: 

Mandatory (M): this element shall always be present and shall appear in the order shown; 

Optional (O): these elements are optional and if they are used, then they shall appear in the 
order shown; 

Conditional (C): this element is conditional depending on another field before that element. If 
this is used, then it shall appear in the order shown; 

NOTE: Unlike the layer 3 PDUs, layer 2 PDUs do not use any n O M bits or "P" bits to indicate 
the presence of optional fields. Whether or not optional fields are present in the PDU 
can be derived by context. 

the value column denotes fixed values or a range of valid values. If this field is empty all bit 
combinations are valid; 

the remarks column defines meanings of the values or it may contain other information on the 
information element. 

21 .2 Logical Link Control (LLC) PDUs description 

The information contained in the following PDU descriptions shall be read from top to bottom. The content 
within an information element shall start with the most significant bit (i.e. the leftmost bit shown in the 
information element descriptions) and shall continue until it reaches the least significant bit. 

21.2.1 LLC PDU types 



Table 304: Definition of LLC PDU types 



LLC type 


PDU associated 


OOOOp 


BL-ADATA (without FCS) 


0001? 


BL-DATA (without FCS) 


0010? 


BL-UDATA (without FCS) 


0011? 


BL-ACK (without FCS) 


0100? 


BL-ADATA (with FCS) 


0101? 


BL-DATA (with FCS) 


0110? 


BL-UDATA (with FCS) 


0111? 


BL-ACK (with FCS) 


1000? 


AL-SETUP 


1001? 


AL-DATA/AL-DATA-AR/AL-FINAL/AL-FINAL-AR 


1010? 


AL-UDATA/AL-UFINAL 


1011? 


AL-ACK/AL-RNR 


1100? 


Reserved 


1101? 


Reserved 


1110? 


Reserved 


1111? 


AL-DISC 



The PDU type field shall have a length of 4 bits. The PDU type values shall be according to table 304. The 
names reflect the functionality inside the LLC. PDUs having the same LLC type values are discriminated 
by additional information elements. Basic link PDUs start with prefix BL, advanced link PDUs start with 
prefix AL. 
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21 .2.2 Basic link PDU definitions 

The following 8 PDUs are defined for the basic link: 

BL-ACK without FCS for the acknowledgement of the previous transmission (BL-DATA or BL- 
ADATA); 

BL-ACK with FCS for the acknowledgement of the previous transmission (BL-DATA or BL-ADATA); 

BL-ADATA without FCS for acknowledgement and the transmission of acknowledged information; 

BL-ADATA with FCS for acknowledgement and the transmission of acknowledged information; 

BL-DATA without FCS for the transmission of acknowledged information; 

BL-DATA with FCS for the transmission of acknowledged information; 

BL-UDATA without FCS for the transmission of unacknowledged information; 

BL-UDATA with FCS for the transmission of unacknowledged information. 
21.2.2.1 BL-ACK 
PDU: BL-ACK; 

service provided: acknowledgement and optional data transfer in basic link; 

response to: BL-DATA or BL-ADATA; 

response expected: none; 

short description: this PDU shall be used to acknowledge one TL-SDU. There are 2 PDUs 

defined, one without and another one with a FCS. The BL-ACK PDUs can carry 
service user data from a TL-DATA response primitive. 

The elements of BL-ACK PDU without FCS shall be as defined in table 305. 

The elements of BL-ACK PDU with FCS shall be as defined in table 306. This PDU shall be used only if a 
TL-SDU is present. 



Table 305: BL-ACK without FCS 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




N(R) 


1 


M 




Received TL-SDU number 


TL-SDU 


variable 


O 




Data from TL-DATA response 
primitive 



Table 306: BL-ACK with FCS 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




N(R) 


1 


M 




Received TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA response 
primitive 


FCS 


32 


M 




Frame Check Sequence 
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21.2.2.2 BL-ADATA 



PDU: BL-ADATA; 

service provided: basic link (acknowledged service in connectionless mode); 

response to: BL-DATA or BL-ADATA. 

response expected: BL-ADATA or BL-ACK. 

short description: there are two PDUs defined, one without and another one with FCS. These 

PDUs shall be used to acknowledge one TL-SDU and send acknowledged data. 

The elements of BL-ADATA PDU without FCS shall be as defined in table 307. 

The elements of BL-ADATA PDU with FCS shall be as defined in table 308. 

Table 307: BL-ADATA without FCS 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




N(R) 


1 


M 




Received TL-SDU number 


N(S) 


1 


M 




Sent TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA request 
primitive 



Table 308: BL-ADATA with FCS 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




N(R) 


1 


M 




Received TL-SDU number 


N(S) 


1 


M 




Sent TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA request 
primitive 


FCS 


32 


M 




Frame Check Sequence 



21.2.2.3 BL-DATA 

PDU: BL-DATA. 

service provided: basic link (acknowledged service in connectionless mode), 

response to: 

response expected: BL-ACK or BL-ADATA. 

short description: there are two PDUs defined, one without and another one with FCS. These 

PDUs shall be used to send acknowledged data. 

The elements of BL-DATA PDU without FCS shall be as defined in table 309. 

The elements of BL-DATA PDU with FCS shall be as defined in table 310. 

Table 309: BL-DATA without FCS 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




N(S) 


1 


M 




Sent TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA request 
primitive 
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Table 310: BL-DATA with FCS 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




N(S) 


1 


M 




Sent TL-SDU number 


TL-SDU 


variable 


M 




Data from TL-DATA request 
primitive 


FCS 


32 


M 




Frame Check Sequence 



21.2.2.4 BL-UDATA 



PDU: BL-UDATA. 

service provided: basic link (unacknowledged service in connectionless mode), 

response to: 

response expected: none 

short description: these PDUs shall be used to send unacknowledged data. There are two 

separate PDU having a different LLC type to indicate whether the PDU contains 
the FCS or not. 

The elements of BL-UDATA PDU without FCS shall be as defined in table 31 1 . 
The elements of BL-UDATA PDU with FCS shall be as defined in table 312. 



Table 31 1 : BL-UDATA without FCS 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




TL-SDU 


variable 


M 




Data from TL-UNITDATA 
request primitive 


Table 312: BL-UDATA with FCS 


Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




TL-SDU 


variable 


M 




Data from TL-UNITDATA 
request primitive 


FCS 


32 


M 




Frame Check Sequence 



21 .2.3 Advanced link PDU definitions 



The advanced link uses 10 different PDUs: 

AL-ACK for an acknowledgement of received information with receive ready flow control indication; 

AL-RNR for an acknowledgement of received information with receive not ready flow control 
indication; 

AL-FINAL for transmission of the last segment of an acknowledged information; 

AL-FINAL-AR for transmission of the last segment of an acknowledged information with an 
acknowledgement request; 

AL-DATA for transmission of an acknowledged information segment; 

AL-DATA-AR for transmission of an acknowledged information segment with acknowledgement 
request; 

AL-DISC for disconnecting the advanced link; 

AL-SETUP for establishment or reset of the advanced link with quality of service negotiation; 
AL-UDATA for transmission of a segment of an unacknowledged information; 
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AL-UFINAL for transmission of the last segment of an unacknowledged information. 

NOTE: The 1 0 different PDUs are presented by 5 different PDU types, see table 304. 

AL-DATA or AL-DATA-AR shall never contain an entire FCS and shall not be used as the last segment of 
a TL-SDU, while AL-FINAL and AL-FINAL-AR shall always contain a FCS or the last part of it and shall be 
used as the last segment of a TL-SDU. 



21.2.3.1 

PDU: 



AL-ACK, AL-RNR 



service provided: 
response to: 
response expected: 
short description: 



AL-ACK (receiver ready with acknowledgement). 
AL-RNR (receiver not ready with acknowledgement), 
acknowledgement in advanced link (connection mode) flow control. 
AL-DATA, AL-DATA-AR, AL-FINAL and AL-FINAL-AR. 
none 

these PDUs shall be used to acknowledge TL-SDUs and/or segments of 
TL-SDUs. They support flow control by reporting "receiver ready" or "receiver 
not ready" to the peer sender. 



The elements of AL-ACK and AL-RNR PDU shall be as defined as follows: 

Table 313: AL-ACK and AL-RNR 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




Flow control 


1 


M 


0 


Receiver not ready (AL-RNR) 


1 


Receiver ready (AL-ACK) 


First Acknowledgement 
Block 


variable 


M 




Acknowledgement of the eldest 
unacknowledged TL-SDU 


Other Acknowledgement 
Blocks 


variable 


0 




Acknowledgement of the next 
unacknowledged TL-SDUs, may 
be repeated up to window size 
N.272 



The acknowledgement block shall be as defined as follows: 

Table 314: Acknowledgement block 



Information element 


Length 


Type 


Value 


Remark 


N(R) 


3 


M 




The number of the TL-SDU 


Acknowledgement length 


6 


M 


000000? 


SDU correctly received 


0000012 


Number of acknowledged 
segments 


...etc. 


...etc. 


1111102 


Number of acknowledged 
segments 


1111112 


Repeat the entire SDU 


S(R) 


8 

note 1 


C 




Sequence number of the eldest 
not yet correctly received 
segment. 


Acknowledgement bit map 


Variable 
note 2 
note 3 


C 


0 


Incorrectly or not yet received 
segment 


1 


Correctly received segment 


NOTE 1: The element is present if the Acknowledgement length is in the range from 000001 2 to 
1 1 1 1 1 0 2 . 

NOTE 2: Length of the bitmap is variable, each bit is set as defined. 

NOTE 3: The element is present if the Acknowledgement length is in the range from 00001 0 2 to 
1 1 1 1 102-The length of the bitmap is Acknowledgement length minus one. 
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The correct reception of an entire TL-SDU shall be indicated by the acknowledgement bit map length set 
to zero (000000 2 ). A TL-SDU FCS failure shall be indicated by the acknowledgement bit map set to 
1 1 1 1 1 1 2 binary. In these cases the acknowledgement block shall not contain the fields S(R) and 
acknowledgement bit map. 

In the other cases the total number of the acknowledged segments shall be equal to the number in the 
acknowledgement length field. In the case 000001 2 binary, only S(R) is present and the bitmap is empty. 
Because the segment indicated by S(R) is implicitly not acknowledged (incorrectly received), the length of 
the bitmap is Acknowledgement length minus one. Acknowledgement bit map shall indicate the reception 
status (STATUS) of the segments following immediately the one indicated by the S(R) and it should 
continue up to the segment with the highest sequence number that has been correctly received. All 
segments prior to the one referred to by the S(R) shall be correctly received. 

The AL-ACK PDU may contain acknowledgement for multiple TL-SDUs. The acknowledgement block 
may appear as many times as the size of TL-SDU window (N.272). 

21 .2.3.2 AL-FINAL, AL-FINAL-AR 

PDU: AL-FINAL (last data of a TL-SDU). 

AL-FINAL-AR (last data of a TL-SDU with immediate acknowledgement 
required). 

service provided: data transfer in advanced link (connection mode), 

response to: 

response expected: AL-ACK to the AL-FINAL-AR; 

short description: these PDUs shall be used to send the last segment in a TL-SDU or a whole 

TL-SDU. When an immediate response is required, AL-FINAL-AR shall be used. 



Table 315: AL-FINAL, AL-FINAL-AR 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




FINAL 


1 


M 


1 


Last segment with FCS 


AR 


1 


M 


0 


No immediate response 
(AL-FINAL) 








1 


Immediate response required 
(AL-FINAL-AR) 


N(S) 


3 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


The last segment of 
TL-DATA SDU 


Variable 
note 1 


O 




The last segment of TL-DATA SDU 


FCS 


32 
note 2 


M 




Frame Check Sequence 


NOTE 1 : This PDU may contain no data from the TL-DATA request primitive, see note 2. 
NOTE 2: The size shown is the upper limit of the FCS field, a part of the FCS could be in the previous 
AL-DATA PDU. 



Page 365 

ETS 300 392-2: March 1996 



21 .2.3.3 AL-DATA, AL-DATA-AR 



PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-DATA (acknowledged information transfer). 

AL-DATA-AR (acknowledged information transfer with immediate response), 
data transfer in advanced link (connection mode). 

AL-ACK to the AL-DATA-AR. 

these PDUs shall be used to send all other segments than the last one of a 
TL-SDU. When the sending entity requests an immediate acknowledgement, 
AL-DATA-AR shall be used. For the transmission of the last segment see 
AL-FINAUAL-FINAL-AR PDU. 



Table 316: AL-DATA, AL-DATA-AR 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




FINAL 


1 


M 


0 


Not the last segment 


AR 


1 


M 


0 


No immediate response (AL-DATA) 








1 


Immediate response required (AL-DATA- 
AR) 


N(S) 


3 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


Segment of TL-SDU 


Varies 


M 




A segment of TL-SDU, The length 
depends on the MAC block used. 



21.2.3.4 AL-DISC 



PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-DISC (disconnection phase of the advanced link), 
disconnection of an advanced link (connection mode). 
AL-DISC, see protocol definition for parameters. 
AL-DISC or none, see protocol definition for parameters, 
this PDU is used to disconnect an advanced link. 



Table 317: AL-DISC 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




Advanced link service 


1 


M 


0 


Unacknowledged service 








1 


Acknowledged service 


Advanced link 


2 


M 


00? 


Advanced link number 1 


number 






01? 


Advanced link number 2 








10? 


Advanced link number 3 








11? 


Advanced link number 4 


Report 


3 


M 


000? 


Success 






001? 


Close 








010? 


Reject 








011? 


Service not supported 








100? 


Service temporarily unavailable 








101? 


Reserved 








...etc. 


...etc. 








111? 


Reserved 
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21.2.3.5 AL-SETUP 



PDU: 

service provided: 
response to: 
response expected: 
short description: 



AL-SETUP (acknowledged or unacknowledged information containing advanced 

link set-up parameters). 

advanced link establishment or reset. 

AL-SETUP in point-to-point case, see protocol. 

AL-SETUP or none in point-to-multipoint case, see protocol. 

this PDU is used to establish the advanced link and to reset an established 

advanced link. 



Table 318: AL-SETUP elements 



Information element 


Length 


Type 


Wall to 


Rom ark 
nci 1 icii vv 


LLC PDU type 


4 


M 


coo tanlo *^ClA 
occ laUlt; OUH 




MQvanceu iinK service 


i 


M 






1 


Af*knnu/lor(noH corvioo 


Advanced link number 
N.261 


2 


M 




AHwanroH link ni imhpr 1 


U 1 2 


AH\/anr>oH link nnmhor 9 


1U 2 


AH\/anr»flH link nnmhor *3 
r\U Val It/tJU 1 II IIS. MUlllUCl O 


112 


AHuannoH link nnmhor 4 
r\UVeUIL>fcftJ III tlV MUlilUCi *+ 


Maximum length of 
aTL-SDUN.271 


3 


M 


nnn« 


Oil UUltJlo 


UU I 2 


ftA /v*totc 
OH- Uv»K*lo 


U I U2 


I Ultimo 


U 1 1 2 


OR ft rvtotc 


I UU2 


CiO rv»toto 


1 U 1 2 


1 C\OA rt/*tote 
1 U^*r UUlclo 


1 1 U2 


O HAft rvtotc 




A HQA rv/"»totc 


Number of timeslots 
used per TDMA frame 
(maximum throughput) 


2 


M 


UU2 


1 UllltJolOl 


UI2 


^ wnesiois 


1 U2 


O UllltJolUlo 


n 2 


A timaolrttc 
H UlllcolUlo 


Data transfer throughput 
(mean value) note 1 


3 


M 


000? 


Network dependent minimum 


001? 


1/32 of maximum 


010? 


1/16 of maximum 


011? 


1/8 of maximum 


100? 


1/4 of maximum 


101? 


1/2 of maximum 


110? 


Reserved 


111? 


Maximum 


TL-SDU window size 
N.272 or N.281 note 2 


2 


M 


00? 


Reserved 


01? 


SDU window size = 1 


10? 


SDU window size = 2 


11? 


SDU window size = 3 


Maximum number of 
TL-SDU re-transmissions 
N.273 or TL-SDU 
repetition N.282 note 3 


3 


M 


000? 


no re-transmissions 


001? 


1 re-transmission 


...etc. 


...etc. 


1112 


7 re-transmissions, 






(continued) 
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Table 318 (concluded): AL-SETUP elements 



Information element 


Length 


Type 


Value 


Remark 


Maximum number of 
segment re-transmissions 
N.274 


4 


M 


0000? 


no re-transmissions 


0001? 


1 re-transmission 


...etc. 


...etc. 


1111? 


15 re-transmissions 


Report 


3 


M 


000? 


Success 


001? 


service definition 


010? 


service change 


011? 


reset 


100? 


Reserved 


101? 


Reserved 


110? 


Reserved 


111p 


Reserved 


N(S), note 4 


8 


C 




Sent TL-SDU number 


NOTE 1 : The BS may use a control channel as a general packet data channel, supporting advanced 
links for many MSs t where each MS may be offering/receiving data packets at a low rate or 
intermittently. This parameter gives the BS the necessary information for planning its 
resource allocations. 

NOTE 2: TL-SDU window sizes N.272 and N.281 are for the acknowledged and unacknowledged 
services respectively. 

NOTE 3: For the acknowledged service the N.273 defines how many times the TL-SDU may be re- 
transmitted and for the unacknowledged (point-to-multipoint) service, N.282 means the 
number of times the TL-SDU will be repeated by the sender. 

NOTE 4: This element is present only for the unacknowledged service (i.e. advanced link service 
element set to w 0"). 



The Data transfer throughput indicates how much of the total throughput of the allocated radio resources 
(timeslots) should be available for the advanced link. Maximum throughput will be realised when there is 
only one MS using the whole capacity of the radio resource allocation. The lower values indicate that the 
same radio resources may be used for multiple advanced links for one or more MS. The values are mean 
values and the usage allocation during the lifetime of an advanced link is outside of the scope of this ETS. 



21.2.3.6 AL-UDATA 

PDU : AL-U DATA (unacknowledged information transfer) . 

service provided: unacknowledged data transfer in advanced link, 

response to: 

response expected: none. 

short description: this PDU is used to send one segment of unacknowledged TL-SDU. 

Table 319: AL-UDATA elements 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




FINAL 


1 


M 


0 


Not the last segment 


N(S) 


8 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


Segment of TL- 
UNITDATA 


Variable 


M 




Segment of TL-UNITDATA 
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21.2.3.7 AL-U FINAL 

PDU: AL-UFINAL (unacknowledged information transfer), 

service provided; data transfer in advanced link, 

response to: 

response expected: none. 

short description: this PDU is used to send the last segment of an unacknowledged TL-SDU in the 

advanced link in the downlink. 



Table 320: AL-UFINAL elements 



Information element 


Length 


Type 


Value 


Remark 


LLC PDU type 


4 


M 


see table 304 




FINAL 


1 


M 


1 


Last segment with FCS 


N(S) 


8 


M 




Sent TL-SDU number 


S(S) 


8 


M 




Sent segment sequence number 


Last Segment of 
TL-UNITDATA 


Variable 
note 1 


0 




Last Segment of TL-UNITDATA 


FCS 


32 
note 2 


M 




FCS 


NOTE 1 : This PDU may contain no data from the TL-UNITDATA request primitive, see note 2. 
NOTE 2: The size shown is the upper limit of the FCS field, a part of the FCS could be in the previous 
AL-UDATA PDU. 



21.3 LLC elements 



21.3.1 FCS 

This element is 32 bits long. 

31 

These bits shall be placed in decreasing order for the power of x. The coefficient of x shall be mapped 
onto the most significant bit. The coefficient of x° shall be mapped onto the least significant bit. The FCS 
calculation is defined in clause 22. 

21.3.2 TL-SDU size 

In the various LLC PDU, one element often appears generally at the end of the PDU: start of TL-SDU. 
This indicates the beginning of the layer 3 information content which does not have a fixed length. 
Sometimes, this element is optional, which means that PDUs shall be exchanged even without layer 3 
specific information. This is generally the case for responses, where the acknowledgement PDU is 
generated by the LLC and may be sent independently from the layer 3 message. On the other hand, the 
segments in an advanced link shall be calculated so that they fit in the MAC offered capacity. 

21 .4 MAC PDU description 

The following subclauses describe the information content of the MAC PDUs. 

The information contained in the following PDU descriptions shall be read from left to right, starting at the 
top and going down. The information content shall start with the most significant bit and shall continue until 
it reaches the least significant bit. 

A MAC PDU is composed of a MAC header and a TM-SDU which is passed to the MAC from the LLC 
layer. The MAC header contains information about the content of the PDU. One MAC block (either a half 
or full timeslot) may contain several independent MAC PDUs, each with their own header. The TM-SDU is 
transported by the MAC, but the MAC shall not have any visibility or knowledge of the SDU content. 
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21.4.1 MAC PDU types 

These MAC PDU types shall be used for C-plane signalling messages, C-plane broadcast messages and 
end-to-end U-plane signalling. 



Table 321: MAC PDU types for SCH/F, SCH/HD, STCH and BSCH 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


00 2 


TMA-SAP: MAC-DATA 








or MAC-RESOURCE 








01 2 


TMA-SAP: MAC-END or MAC-FRAG 








10 2 


TMB-SAP: Broadcast 








11 2 


TMD-SAP: MAC-U-SIGNAL 










(U-plane signalling) 



The PDU types shown in table 321 may be used for the transmission of signalling information in full slots 
on the uplink and downlink and in half slots on the downlink. Under normal operation, the MS shall use 
MAC-DATA for transmission on the uplink and the BS shall use MAC-RESOURCE for transmission on the 
downlink. MAC-FRAG and MAC-END shall be used on the uplink and downlink for transmission of 
continuations and end of a fragmented SDU. Three types of broadcast PDU are defined, namely SYNC, 
SYSINFO and ACCESS-DEFINE. These PDUs shall be used by the BS to transmit broadcast information 
on the downlink. MAC-U-SIGNAL shall be used by both MS and BS for the transmission of U-plane 
signalling information. 



Table 322: MAC PDU Types for SCH/HU 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


1 


M 


0 
1 


TMA-SAP: MAC-ACCESS 
TMA-SAP: MAC-END-HU 



The PDU types shown in table 322 may be used for the transmission of signalling information in half slots 
(i.e. subslots) on the uplink. The half slot signalling channel on the uplink may be recognised by a 
particular training sequence. The MS may transmit signalling information on the half slot uplink using the 
MAC-ACCESS PDU. The MS may also use the MAC-END-HU PDU for transmission of the end of a 
fragmented SDU. 



The following subclauses describe the contents of each of these uplink, downlink and broadcast PDUs. 
21 .4.2 TMA-SAP: MAC PDU structure for the uplink 

The following subclauses describe the MAC PDUs which may be sent on the uplink and which contain 
C-plane signalling information from the TMA-SAP in the MS. 



Page 370 

ETS 300 392-2: March 1996 
21.4.2.1 MAC-ACCESS 

This PDU may be used to send C-plane signalling data on the uplink in a subslot (SCH/HU). It shall be 
used for random access and may also be used for reserved access in a subslot. Its contents are shown 
as follows: 



Table 323: MAC-ACCESS PDU contents 



Information 
element 


Length 


Type 


Value 


Remark 


PDU type 


1 


M 


0 


MAC-ACCESS 


Fill bit indication 


1 


M 


0 


No fill bits present 


1 


Fill bit(s) present 


Encrypted flag 


1 


M 


0 


Not Encrypted 


1 


Encrypted 


Address type 


2 


M 


OOp 


SSI 


01? 


Event Label (address length 10, see note) 


10? 


USS! (migrating MS un-exchanged address) 


11p 


SMI (management address) 


Address 


24/10 


M 




SSI, USSI, SMI or Event Label according to 
address type 


Optional field 
flag 


1 


M 


0 


No length indication nor capacity request 


1 


Length indication or capacity request 


Length indication 
or capacity request 


1 


C 


0 


Length indication 


1 


Capacity request (i.e. fragmentation flag + 
reservation requirement) 


Length indication 


5 


C 


00000? 


Null PDU 


00001? 


Reserved 


00010? 


Reserved 


00011? 


Lenqth of MAC PDU in octets 


...etc. 


...etc. 


01100? 


Lonqest MAC-PDU 


01101? 


Reserved 


...etc. 


...etc. 


11111? 


Reserved 


Fragmentation 
flag 


1 


c 


0 


TM-SDU not fragmented 


1 


Start of fragmentation 


Reservation 
requirement 


4 


C 




see reservation requirement element definition 


TM-SDU 


varies 


C 






NOTE: The address lenqth of the other address types is 24. 



The SCH/HU is distinguished by a particular training sequence. The first bit of the MAC header 
distinguishes between the two possible PDU types which can be sent on SCH/HU. 



The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the 
TM-SDU is less than the available capacity of the SCH/HU MAC block or less than the size of the TM- 
SDU indicated by the length* indication field. The TM-SDU length is equal to the MAC PDU length minus 
the MAC PDU header length. 

The encrypted flag shall indicate whether or not the TM-SDU contents are encrypted. The MAC header 
shall not be encrypted but an alias stream may be used to encrypt the address, in the case of 
fragmentation, the setting of the encrypted flag in the MAC-ACCESS PDU shall apply to all fragments of 
that TM-SDU. 

The address type field shall indicate the type of address contained in the address field. The length of the 
address field shall be 10 bits for an event label or 24 bits for SSI, USSI or SMI. 
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The optional field flag shall indicate whether any of the optional fields are present in the PDU header. If 
optional fields are present the next bit (length indication or capacity request) shall indicate whether the 
header contains a length indication field or a capacity request field. If length indication is indicated, then 
the next field shall be length indication. Length indication shall refer to the length of the MAC PDU (which 
comprises the MAC PDU header and the TM-SDU) and should be used only if association within the 
uplink half slot is required or for transmission of the null PDU. 

The header length of a MAC-ACCESS PDU depends on the type of address in use and whether or not 
there is a length indication or capacity request. The header length and maximum TM-SDU length is shown 
in table 325 for each of the possible combinations. 

The length indication field may be used to indicate a null PDU. If a null PDU is indicated, there shall be no 
further information in the PDU after the length indication field. The length of the null PDU, therefore, shall 
be 22 bits if an event label is used as an address or 36 bits if an SSI, USSI or SMI is used as an address. 
The null PDU, if it appears in a MAC block, shall always be the last PDU in that block. Any spare capacity 
after the null PDU shall be filled with fill bits. 



Table 324: Length of MAC-ACCESS PDU header and SDU 



Content of Header Fields 


Header Length 
[bits] 


Maximum TM-SDU Length 
[bits] 


Address = Event Label 

No length indication nor capacity request 


16 


76 


Address = SSI, USSI or SMI 

No length indication nor capacity request 


30 


62 


Address = Event Label 

Length indication or capacity request 


22 


70 


Address = SSI, USSI or SMI 
Lenqth indication or capacity request 


36 


56 



If capacity request is indicated in the length indication or capacity request bit, the next field shall be 
fragmentation flag followed by reservation requirement. Capacity request shall be used when the MS has 
further signalling to send, which may or may not be subsequent fragments of a fragmented SDU (as 
indicated by the fragmentation flag). The PDU may only contain either the length indication field or the 
capacity request field (comprising fragmentation flag and reservation requirement), but not both. 



NOTE: An MS generally sets the "Optional field flag" to V only for transmission of the Null 
PDU or if PDU association is required within the subslot or if the MS has further 
signalling messages ready to be sent. Otherwise the flag is set to "0" giving a 
maximum TM-SDU length of 62 bits (or 76 bits if an event label is used). 

The "Optional field flag" is provided in the PDU in order to economise on the use of bits 
for the most usual cases. It is not provided in the MAC-END-HU, MAC-DATA or 
MAC-END PDUs, in which the size constraint is less critical. 

For example, the defined structure of the MAC-ACCESS PDU allows the CMCE 
U-SETUP PDU to be sent within a subslot, provided that: 

(a) the full TSI of the called party is not needed in the U-SETUP PDU; and 

(b) the FCS is not added by the LLC; and 

(c) the MAC does not include a capacity request so that the optional field 
flag = "O" (or an event label is used for addressing). 
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21.4.2.2 MAC-END-HU 

This PDU shall be used to send the last fragment of fragmented C-plane signalling data on the uplink 
using a subslot (SCH/HU). Its contents are shown as follows: 



Table 325: MAC-END-HU PDU contents 



Information element 

111 1 \f 1 1 1 IllifVI ■ vl v 1 1 IWI ■ » 


Length 


Tvoe 


Value 


Remark 


PDU type 


1 


M 


1 


MAC-END-HU 


Pill Hit inHi^atinn 
r 111 Ull H lUlwdllU1 1 


1 
i 


M 

IVI 


o 


No fill bits Dresent 

1 IV llll Ul Iw ys ■ w WW 1 1 1 


1 


Fill bit(s) present 


Length indication 
or capacity request 


1 


M 


0 


Length indication 


1 


Reservation requirement 
(i.e. Capacity request) 


Length indication 


4 


C 


0000 2 

0001 2 
...etc. 
HOO2 
1101 2 
...etc. 
11112 


Reserved 

Length of PDU in octets 
...etc. 

Longest PDU 
Reserved 
...etc. 
Reserved 


Reservation 
requirement 


4 


C 




see reservation requirement element definition 


TM-SDU 


varies 


c 







The SCH/HU is distinguished by a particular training sequence. The first bit of the MAC header 
distinguishes between the two possible PDU types which can be sent on SCH/HU. 



The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the 
TM-SDU is less than the available capacity of the SCH/HU or less than the size of the TM-SDU indicated 
by the length indication field. The TM-SDU length is equal to the MAC PDU length minus the MAC PDU 
header length. 

The length indication or capacity request field shall indicate whether the header contains a length 
indication field or a capacity request field. If length indication is indicated, then the next field shall be length 
indication. Length indication shall refer to the length of the MAC PDU which comprises the MAC PDU 
header and the TM-SDU The length indicator shall be used if association within the uplink half slot is 
required or if the MS has no further signalling to send. If reservation requirement is indicated, the next field 
shall be reservation requirement which shall be used when the MS has further C-plane signalling 
messages ready to send. In that case the length of the TM-SDU is defined by the fill bit mechanism. The 
PDU may only contain either the length indication field or the reservation requirement field. 

The header length of a MAC-END-HU PDU shall be equal to 7 bits. So the length of the TM-SDU shall not 
exceed 85 bits. 



Page 373 
ETS 300 392-2: March 1996 

21.4.2.3 MAC-DATA 

This PDU may be used to send C-plane signalling data on the uplink in a full slot (SCH/F). It may also be 
used to send C-plane signalling data in the first half of a full uplink slot using the stealing channel (STCH). 
If the second half of a full uplink slot is also stolen, the MAC-DATA PDU may be used to send another C- 
plane PDU in the second half slot. Its contents are shown as follows: 



Table 326: MAC-DATA PDU contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


00 2 


MAC-DATA 


Fill bit indication 


1 


M 


0 


No fill bit present 


1 


Fill bit(s) present 


Encrypted flag 


1 


M 


0 


Not encrypted 


1 


Encrypted 


Address type 


2 


M 


00 2 
01 2 
10 2 

11? 


SSI 

Event Label (address length 10, note) 
USSI (migrating MS un-exchanged address) 
SMI (management address) 


Address 


24/10 


M 




SSI, USSI, SMI or Event Label according to 
address type 


Length indication or 
capacity request 


1 


M 


0 


Length indication 


1 


Capacity request (i.e. fragmentation flag + 
reservation requirement + reserved bit) 


Length indication 


6 


C 


000000? 


Null PDU 


000001 2 


Reserved 


000010? 


Reserved 


000011? 


Length of MAC PDU in octets 


...etc. 


...etc. 


100010? 


Longest MAC PDU 


100011 2 


Reserved 


...etc. 


...etc. 


111101? 


Reserved 


111110? 


Second half slot stolen on STCH 


1111112 


Start of fragmentation on STCH 


Fragmentation flag 


1 


C 


0 


TM-SDU not fragmented 


1 


Start of fragmentation 


Reservation 
requirement 


4 


C 




see reservation requirement element definition 


Reserved 


1 


C 


0 


Default Value 


1 


Not used in this version of ETS 


TM-SDU 


varies 


C 






NOTE: The address length of the other address types is 24. 



The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the 
uplink SCH/F or STCH. 



The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the 
TM-SDU is less than the available capacity of the MAC block or less than the size of the TM-SDU 
indicated by the length indication field. The TM-SDU length is equal to the MAC PDU length minus the 
MAC PDU header length. 

The encrypted flag shall indicate whether or not the TM-SDU contents are encrypted. The MAC header 
shall not be encrypted but an alias stream may be used to encrypt the address. In the case of 
fragmentation, the setting of the encrypted flag in the MAC-DATA PDU applies to all fragments of the TM- 
SDU. 

The address type field shall indicate the type of address contained in the address field. The length of the 
address field shall be 10 bits for an event label or 24 bits for SSI, USSI or SMI. 
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The length indication or capacity request field shall indicate whether the header contains a length 
indication field or a capacity request field. If length indication is indicated, then the next field shall be length 
indication. Length indication shall refer to the length of the MAC PDU (which comprises the MAC PDU 
header and the TM-SDU) and shall be used if association is required or if the MS has no further signalling 
to send. If capacity request is indicated, the next field shall be fragmentation flag followed by reservation 
requirement and the reserved bit. Capacity request shall be used on SCH/F when the MS has further 
signalling to send, which may or may not be subsequent fragments of a fragmented SDU (as indicated by 
the fragmentation flag). The PDU may only contain either the length indication field or the capacity request 
field (comprising fragmentation flag, reservation requirement and the reserved bit). 

The header length of a MAC-DATA PDU depends on the type of address in use. It shall be 37 bits when 
an SSI, USSI or SMI is used and 23 bits when an event label is used. So the length of the TM-SDU shall 
not exceed 231 bits and 245 bits respectively. The length indicated in the MAC PDU header shall refer to 
the entire MAC PDU which comprises the MAC PDU header and the TM-SDU. 

The length indication field may be used to indicate a null PDU. If a null PDU is indicated, there shall be no 
further information in the PDU after the length indication field. The length of the null PDU, therefore, shall 
be 23 bits if an event label is used as an address or 37 bits if an SSI, USSI or SMI is used as an address. 
After a null PDU, there shall be no further PDUs in the MAC block and the remaining capacity shall 
contain fill bits. 

This MAC-DATA PDU shall also be used for C-plane signalling using the STCH on the uplink. By default, 
the STCH occupies only the first half slot. The maximum length of the TM-SDU for a half slot on the uplink 
using the STCH shall be 87 bits when an SSI, USSI or SMI is used or 101 bits when an event label is 
used. The second half slot may also be stolen, either for the last fragment of a fragmented SDU or for 
subsequent PDUs which the MAC may have ready to send or for U-plane signalling. A length indication of 
"11111 1 2 tt shall be used to indicate that the second half slot is stolen for the last fragment of a fragmented 
SDU. A length indication of "1111102" shall be used to indicate that the second half slot is stolen for 
subsequent C-plane signalling or U-plane signalling. The last fragment shall use the MAC-END PDU while 
subsequent C-plane PDUs shall use the MAC-DATA PDU and U-plane signalling shall use the MAC-U- 
SIGNAL PDU. It shall only be possible to fragment SDUs over the two halves of a full slot on the STCH. 

21 .4.2.4 MAC-FRAG (uplink) 

This PDU shall be used to send continuation fragments of fragmented C-plane signalling data on the 
uplink using a full slot (SCH/F). Its contents are shown as follows: 



Table 327: MAC-FRAG (uplink) PDU contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


01 p 


MAC-FRAG or MAC-END 


PDU subtype 


1 


M 


0 


MAC-FRAG 


Fill bit indication 


1 


M 


0 


No fill bits present 








1 


Fill bit(s) present 


TM-SDU 


varies 


M 







The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the 
uplink using a full slot. A PDU subtype bit distinguishes between MAC-FRAG and MAC-END which share 
the same PDU type. 



The fill bit indication shall indicate if there are any fill bits which shall be added whenever the size of the 
TM-SDU fragment is less than the available capacity of a full slot. Fill bits may be required for this PDU 
because the MAC-END header length is greater than the header length of this PDU. This means that it is 
possible that the last fragment of an SDU may be too large to fit into a MAC-END PDU but too small to fill 
the maximum TM-SDU space available in the MAC-FRAG PDU. In this case, fill bits are required in the 
MAC-FRAG PDU and MAC-END shall be sent with a zero-length TM-SDU. 

The header length of a MAC-FRAG shall be equal to 4 bits. So the maximum length of the TM-SDU field 
shall be 264 bits. 
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21.4.2.5 MAC-END (uplink) 

This PDU shall be used to send the last fragment of fragmented C-plane signalling data on the uplink 
using a full slot (SCH/F). It shall also be used to send the last fragment of fragmented C-plane signalling in 
the second half of a stolen full slot on the uplink. Its contents are shown as follows: 



Table 328: MAC-END (uplink) PDU contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


01? 


MAC-FRAG or MAC-END 


PDU subtype 


1 


M 


1 


MAC-END 


Fill bit indication 


1 


M 


0 


No fill bits present 








1 


Fill bit(s) present 


Length indication / 

reservation 

requirement 


6 


M 


0000002 

000001 2 
00001 0 2 

etc 
1000102 
100011 2 

...etc. 
1011112 
11xxxx2 


Reserved 
Reserved 

Length of MAC PDU in octets 
...etc. 

Longest MAC PDU 
Reserved 
...etc. 
Reserved 

See reservation requirement element 
definition 


TM-SDU 


varies 


C 







The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the 
uplink SCH/F or STCH. A PDU subtype bit distinguishes between MAC-FRAG and MAC-END which share 
the same PDU type. 



The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the 
PDU is less than the available capacity of the MAC block or less than the size of the PDU indicated by the 
length indication field. The TM-SDU length is equal to the MAC PDU length minus the MAC PDU header 
length. 

The next 6-bit field shall indicate length indication or a reservation requirement. A value from "00001 02" to 
w 100010 2 " shall indicate the length of the PDU. A value beginning with "Ha" shall indicate a reservation 
requirement which shall be used on SCH/F when the MS has further C-plane signalling to send. The 
reservation requirement information is contained in the 4 least significant bits of these values, the meaning 
of which is given in the reservation requirement element definition. 

The header length of a MAC-END PDU shall be equal to 10 bits. So the length of the TM-SDU shall not 
exceed 258 bits or 114 bits, when SCH/F or STCH is used respectively. The length indicated in the MAC 
PDU header shall refer to the MAC PDU which comprises the MAC PDU header and the TM-SDU. 

21 .4.3 TM A-SAP: MAC PDU structure for the downlink 

The following subclauses describe the MAC PDUs which may sent on the downlink and which contain 
C-plane signalling information for the TMA-SAP in the MS. 

21.4.3.1 MAC-RESOURCE 

This PDU may be used to send C-plane signalling data on the downlink in a full slot (SCH/F) or in the first 
or second half slot of a full slot (SCH/HD). It may also be used to send C-plane signalling data in the first 
half of a downlink slot using the stealing channel (STCH). If the second half of a downlink slot is also 
stolen, the MAC-RESOURCE PDU may be used to send another PDU in the second half slot. 
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This PDU may be sent without a TM-SDU in order to allocate uplink capacity, send a channel allocation or 
control mobile transmit power. Its contents are shown as follows: 



Table 329: MAC-RESOURCE PDU contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


00p 


MAC-RESOURCE 


Fill bit indication 


1 


M 


0 


No fill bits present 


1 


Fill bit(s) present 


Position of grant 


1 


M 


0 


Slot grant (if any) is on current channel 


1 


Slot grant (if any) is on allocated channel 


Encryption mode 


2 


M 


002 


Not encrypted 


01? 


Encrypted with algorithm 1 


10p 


Encrypted with algorithm 2 


11p 


Encrypted with algorithm 3 


Random access flag 


1 


M 


0 


Undefined 


1 


Random Access Acknowledged 


Length indication 


6 


M 


OOOOOOp 


Reserved 


000001 p 


Reserved 


00001 0 2 


Length for null PDU 


000011 2 


Reserved 


0001 00 2 


Length of MAC PDU in octets 


...etc. 


...etc. 


10001 Op 


Longest MAC PDU in octets 


100011? 


Reserved 


...etc. 


...etc. 


111101? 


Reserved 


11 1 1 1 0p 


Second half slot stolen in STCH 


1111 11p 


Start of fragmentation 


Address type 


3 


M 


000 2 


Null PDU 


001 2 


SSI 


01 0 2 


Event Label 


0112 


USSI (migrating MS un-exchanged address) 


1002 


SMI (management address) 


101 2 


SSI + Event Label (event label assignment) 


110 2 


SSI + Usage Marker (usage marker 
assignment) 


111p 


SMI + Event Label (event label assignment) 


Address 


34/ 
30/ 
24/ 
10 


M 




SSI/SMI + Event Label 
SSI + Usage Marker 
SSI, USSI or SMI 
Event Label 


Power control flag 


1 


M 


0 


No power control element in PDU 


1 


Power control element in PDU 


Power control element 


4 


C 




see power control element definition 


Slot granting flag 


1 


M 


0 


No slot granting elements in PDU 


1 


Slot granting element in PDU 


Slot granting element 


8 


C 




see slot granting element definition 


Channel allocation 
flag 


1 


M 


0 


No channel allocation element in PDU 


1 


Channel allocation element in PDU 


Channel allocation 
element 


variable 


C 




see channel allocation element definition 


TM-SDU 


variable 


C 







The first two bits of the MAC header distinguish between the possible PDU types which can be sent in the 
downlink MAC block. 
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The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the 
TM-SDU is less than the available capacity of the MAC block or less than the size of the TM-SDU 
indicated by the length indication field. The TM-SDU length is equal to the MAC PDU length minus the 
MAC PDU header length. 

The position of grant element indicates the channel on which the optional slot grant is valid. If there is no 
slot granting in this PDU, the MAC shall ignore the content of this bit. 

The encrypted mode field shall indicate whether or not the TM-SDU contents are encrypted and, if so, the 
encryption algorithm used. Only the channel allocation element in the MAC header may be encrypted and 
an alias stream may be used to encrypt the address. In the case of fragmentation, the setting of the 
encrypted mode field in the MAC-RESOURCE PDU shall apply to all fragments of the TM-SDU. 

The random access flag shall be used for the BS to acknowledge a successful random access so as to 
prevent the MS sending further random access requests. 

The length indication field shall indicate the length of the MAC PDU which comprises the MAC PDU 
header and the TM-SDU. If the length indication field has value of -1111112", then this shall indicate the 
beginning of a fragmented signalling message. 

The address type field shall indicate the type of address(es) contained in the address field. The length of 
the address field shall be 10, 24, 30 or 34 bits depending on the type of address information contained in 
it. 

The power control flag shall indicate whether the optional power control element is present in this PDU. 
The slot granting flag shall indicate whether the optional slot granting element is present in this PDU. The 
channel allocation flag shall indicate whether the optional channel allocation element is present in this 
PDU. 

The header length of a MAC-RESOURCE PDU depends on the type of address information and on which 
of the optional fields are present. The minimum length shall be 29 bits when an event label is used and 
there are no optional fields present. So the length of the TM-SDU shall not exceed 239 bits or 95 bits, 
when SCH/F or SCH/HD is used respectively. The length indicated in the MAC PDU header shall refer to 
the MAC PDU which comprises the MAC PDU header and the TM-SDU. 

The address type field may be used to indicate a null PDU(address type = ,, 0002 ,, ). If a null PDU is 
indicated, there shall be no further information in the PDU after the address type field. The length of the 
null PDU, therefore, shall be 16 bits. On STCH, the length indication field may indicate whether the 
second half slot is stolen. All other fields in a null PDU (i.e. Fill bit indication, Position of grant, Encryption 
mode, and Random access flag) may be set to any value by the BS and shall be ignored by the MS in this 
ETS). If the null PDU is present in a MAC block, then there shall be no subsequent PDUs in that block and 
any spare capacity shall be filled with fill bits. 

This PDU shall also be used for C-plane signalling using the STCH on the downlink. By default, the STCH 
occupies only the first half slot. The maximum length of the TM-SDU for a half slot on the downlink using 
the STCH shall be 95 bits when an event label is used. The second half slot may also be stolen, either for 
the last fragment of a fragmented SDU or for subsequent PDUs which the MAC may have ready to send 
or for U-plane signalling. A length indication of "1 1 1 1 1 V shall be used to indicate that the second half slot 
is stolen for the last fragment of a fragmented SDU. A length indication of "IIIHO2" shall be used to 
indicate that the second half slot is stolen for subsequent C-plane signalling or U-piane signalling. The last 
fragment shall use the MAC-END PDU while subsequent C-plane PDUs shall use the MAC-RESOURCE 
PDU and U-plane signalling shall use the MAC-U-SIGNAL PDU. It shall only be possible to fragment 
SDUs over the two halves of a full slot on the STCH. 
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21 .4.3.2 MAC-FRAG (downlink) 

This PDU shall be used to send continuation fragments of fragmented C-plane signalling data on the 
downlink using half slot (SCH/HD) or full slot (SCH/F) signalling. Its contents are shown as follows: 



Table 330: MAC-FRAG (downlink) PDU contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


01? 


MAC-FRAG or MAC-END 


PDU subtype 


1 


M 


0 


MAC-FRAG 


Fill bit indication 


1 


M 


0 


No fill bits present 








1 


Fill bit(s) present 


TM-SDU 


varies 


M 







The first two bits of the MAC header distinguish between the possible PDU types which can be sent on the 
downlink. A PDU subtype bit distinguishes between MAC-FRAG and MAC-END which share the same 
PDU type. 



The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the 
TM-SDU is less than the available capacity of the MAC block. 

The header length of a MAC-FRAG PDU shall be equal to 4 bits. So the length of the TM-SDU shall not 
exceed 264 bits or 120 bits, when SCH/F or SCH/HD is used respectively. 

21 .4.3.3 MAC-END (downlink) 

This PDU shall be used to send the last fragment of fragmented C-plane signalling data on the downlink in 
a full slot (SCH/F) or the first or second half of a full slot (SCH/HD). It shall also be used to send the last 
fragment of fragmented C-plane signalling in the second half of a stolen full slot on the downlink. Its 
contents are shown as follows: 



Table 331: MAC-END (downlink) PDU contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


01 2 


MAC-FRAG or MAC-END 


PDU subtype 


1 


M 


1 


MAC-END 


Fill bit indication 


1 


M 


0 


No fill bits present 


1 


Fill bit(s) present 


Position of grant 


1 


M 


0 


Slot grant is on current channel 


1 


Slot grant is on allocated channel 


Length indication 


6 


M 


000000? 


Reserved 


000001 2 


Reserved 


00001 0 2 


Length of MAC PDU in octets 


...etc. 


...etc. 


1000102 


Longest MAC PDU 


100011? 


Reserved 


...etc. 


...etc. 


111111p 


Reserved 


Slot granting flag 


1 


M 


0 


No slot granting elements in PDU 


1 


Slot granting element in PDU 


Slot granting element 


8 


C 




see slot qrantina element definition 


Channel allocation 
flag 


1 


M 


0 


No channel allocation element in PDU 


1 


Channel allocation element in PDU 


Channel allocation 
element 


varies 


C 




see channel allocation element definition 


TM-SDU 


varies 


C 







The first two bits of the MAC header shall distinguish between the possible PDU types which can be sent 
on the downlink. A PDU subtype bit distinguishes between MAC-FRAG and MAC-END which share the 
same PDU type. 
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The fill bit indication shall indicate if there are any fill bits, which shall be added whenever the size of the 
TM-SDU is less than the available capacity of the MAC block or less than the size of the TM-SDU 
indicated by the length indication field. The TM-SDU length is equal to the MAC PDU length minus the 
MAC PDU header length. 

The position of grant element indicates the channel on which the optional slot grant is valid. If there is no 
slot granting in this PDU, the MAC shall ignore contents of this bit. 

The length indication field shall indicate the length of the MAC PDU which comprises the MAC PDU 
header and the TM-SDU. 

The slot granting flag shall indicate whether the slot granting element is contained in this PDU. The slot 
granting element may be used to allocate some uplink reserved slots for an MS. 

The channel allocation flag shall indicate whether the channel allocation element is contained in this PDU. 
The channel allocation element may be used to direct MS to a channel at the end of a fragmented 
downlink message. 

The minimum header length of a MAC-END PDU shall be equal to 13 bits. So the length of the TM-SDU 
shall not exceed 255 bits or 111 bits, when SCH/F or either SCH/HD or STCH is used. The length 
indicated in the MAC PDU header shall refer to the MAC PDU which comprises the MAC PDU header and 
the TM-SDU. 

21 .4.4 TMB-SAP: MAC PDU structure for broadcast 

Broadcast PDUs shall be used by the BS to send some broadcast information on the downlink to all MS. 
There shall be no addresses contained in these PDUs and all MS shall decode them as if they were 
addressed to each of them. The SYNC PDU shall be transmitted using the BSCH which shall be sent 
using the synchronisation burst. There is no PDU type element in the SYNC PDU. The other broadcast 
PDU types shall be distinguished by a PDU type and broadcast type as shown as follows: 



Table 332: Broadcast PDU contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


10? 


Broadcast PDU 


Broadcast type 


2 


M 


00? 


SYSINFO PDU (BNCH content) 


01? 


ACCESS-DEFINE PDU 


10? 


Reserved 


11? 


Reserved 


Broadcast elements 








See following definitions for SYSINFO and 
ACCESS-DEFINE PDUs 



The following subclauses describe the contents of the three types of broadcast PDU. 
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21.4.4.1 SYSINFO 

The SYSINFO PDU shall be transmitted using the BNCH. Its contents are shown as follows: 



Table 333: SYSINFO element contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


10? 


Broadcast PDU 


Broadcast type 


2 


M 


00? 


SYSINFO PDU 


Main carrier 


12 


M 




Frequency of the MCCH 


Frequency band 


4 


M 




Frequency band of the MCCH 


Offset 


2 


M 


00 2 


0 kHz offset 


01? 


+ 6,25 kHz offset 


10 2 


- 6,25 kHz offset 


11? 


+ 12,5 kHz offset 


Duplex spacing 


3 


M 




Provision for different duplex spacing 


Reverse operation 


1 


M 


0 


Normal 


1 


Reverse 


Number of common 
secondary control 
channels in use 


2 


M 


00? 


None 


01? 


Timeslot 2 of main carrier 


10? 


Timeslots 2 and 3 of main carrier 


11p 


Timeslots 2, 3 and 4 of main carrier 


MS_TXPWR_MAX_ 
CELL 


3 


M 


000? 


Reserved 






001? 


15dBm 


...etc. 


...etc. 


111? 


45 dBm (5dB steps) 


RXLEV_ACCESS_ 
MIN 


4 


M 


0000? 


- 125 dBm 


...etc. 


...etc. 


1111? 


- 50 dBm (5 dB steps) 


ACCESS. 
PARAMETER 


4 


M 


0000? 


- 53 dBm 


...etc. 


...etc. 


1111? 


- 23 dBm (2 dB steps) 


RADIOJDOWNLINK 
.TIMEOUT 


4 


M 


0000? 


Disable radio downlink counter 


0001? 


144 timeslots 


0010? 


288 timeslots 


...etc. 


...etc. 


1111? 


2 1 60 timeslots (multiples of 144) 


Hyperf rame / 
CCK flag 


1 


M 


0 


Hyperframe number 


1 


Common cipher key identifier 


Hyperframe number 


16 


C 




Cyclic count of hyperf rames 


CCK identifier 


16 


C 




Common cipher key identifier 


Optional field flag 


2 


M 


00? 


Even multiframe definition for TS mode 


01? 


Odd multiframe definition for TS mode 


10? 


Default definition for access code A 


11p 


Reserved Field 


TS_COMMON_ 
FRAMES either for Even 
or Odd multiframes 


20 


C 




Bit map of common frames for TS mode, 
see element description 


Default definition for 
access code A 


20 


C 




see table 334 


Reserved Field 


20 


C 




Reserved 


TM-SDU (MLE data) 


42 


M 




as defined in clause 18 
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The frequency of the main carrier shall be defined by the following information elements: 
main carrier; 
frequency band; 
offset; 

duplex spacing; 
reverse operation. 

The frequency band field shall map to a specific frequency which shall map to a defined base frequency 
(in MHz) for the carrier numbering scheme. The main carrier field shall indicate the carrier frequency 
relative to the base frequency defined by the frequency band field. The main carrier field shall have step 
size of 25 kHz. The offset field shall then adjust the main carrier frequency by the given amount. (The 
offset field allows for the case where the carrier frequency is not N * 25 kHz above the base frequency.) 
The frequency so defined shall be the downlink frequency of the main carrier. This calculation shall be 
summarised by the following equation: 

downlink main carrier frequency = base frequency + (main carrier * 25 kHz) + offset kHz. 

The uplink frequency of the main carrier shall be determined using the duplex spacing and reverse 
operation fields. The duplex spacing field shall map to a defined duplex spacing (in MHz) for the carrier 
numbering scheme. The reverse operation field shall indicate whether to add or subtract the duplex 
spacing to arrive at the uplink frequency of the main carrier. If normal operation, the duplex spacing shall 
be subtracted. If reverse operation, the duplex spacing shall be added. This calculation is summarised by 
the following equations: 

normal operation: 

uplink main carrier frequency = downlink main carrier frequency - duplex spacing; 
reverse operation: 

uplink main carrier frequency = downlink main carrier frequency + duplex spacing. 

The mapping of the frequency band field values to actual base frequencies and the duplex spacing field 
values to actual duplex frequency spacing is outside the scope of this ETS. This mapping may be defined 
by frequency regulators according to the frequency allocations for TETRA. 

NOTE: These rules for calculation of uplink and downlink carrier frequency are also used for 
calculation of the carrier frequency in the channel allocation element. 

RXLEV_ACCESS_MIN shall be used for cell selection and re-selection. ACCESS_PARAMETER shall be 
used for subsequent power adjustments. 

The hyperframe/CCK flag shall indicate whether the following element is the hyperframe number or CCK 
identifier. The CCK identifier is a key to a common cipher key used for encryption. 

The optional field flag indicates which one of the optional information elements is present. 

The TS_COMMON_FRAMES element shall only be present if "Discontinuous TX" and "MCCH sharing" is 
indicated in the SYNC broadcast PDU. The optional field shall indicate whether TS_COMMON_FRAMES 
refers to odd or even multiframe definition. 
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Table 334: Default definition for access code A 



Information element 


Length 


Type 


Value 


Remark 


IMM (immediate) 


4 


M 


0000 2 


Always randomise 


0001 2 


Randomise after IMM TDMA frames 


...etc. 


...etc. 


11102 


Randomise after IMM TDMA frames 


11112 


Immediate access allowed 


WT (waiting time) 


4 


M 


OOOO2 


Reserved 


0001 2 


Response within WT downlink opportunities 


...etc. 


...etc. 


11112 


Response within WT downlink opportunities 


Nu (number of 
random access 
transmissions on 
uplink) 


4 


M 


OOOO2 


No random access transmission allowed 


0001 2 


1 random access transmission allowed 


...etc. 


...etc. 


11112 


15 random access transmissions allowed 


Frame length factor 


1 


M 


0 


Multiply base frame length by 1 


1 


Multiply base frame length by 4 


Timeslot pointer 


4 


M 


OOOO2 


Same as downlink slot assignment 


0001 2 


Timeslot 4 


001 Op 


Timeslot bit map 


...etc. 


...etc. 


11102 


Timeslot bit map 


1111p 


All four timeslots 


Minimum priority 


3 


M 


000p 


Priority 0 (lowest) 


...etc. 


...etc. 


1112 


Priority 7 (highest) 



If the optional field flag indicates a default access definition, then the 20-bit field corresponding to the 
default access code definition for access code A shall be present. Its contents are defined in table 334. 



If the optional field flag indicates the reserved field, then the bits of that 20-bit field shall be set to "0" 
(default value). 

Each of the optional fields comprises 20 bits (including reserved bits) so that the SYSINFO PDU fully 
occupies all 124 bits of the MAC block in all cases. 

21.4.4.2 SYNC 

The SYNC PDU shall be transmitted using the BSCH and so shall be distinguishable by the 
synchronisation burst which has a special training sequence. Its contents are shown in table 335. 

The sharing mode field shall indicate whether the BS is using continuous transmission, carrier sharing, 
MCCH sharing or traffic carrier sharing. If MCCH sharing is indicated, the TS reserved frames field shall 
indicate which frames are reserved in this mode of operation. For the other values of sharing mode, the 
contents of the TS reserved frames field shall be ignored. 

The frame 18 extension element shall indicate whether an MS is allowed to receive downlink information 
on all slots of the frame 18. If extension is allowed, only MSs which are capable of receiving consecutive 
slots are able to perform this function. 

The U-plane DTX flag shall indicate whether discontinuous U-plane transmission is supported on traffic 
channels. 
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Table 335: SYNC PDU contents 



Information element 


Length 


Type 


Value 


Remark 


System code 


4 


M 


0000? 


First release of ETS 300 392 (V+D) 






Oxxx? 


V+D reserved 








1yyy 2 


PDO system 


Colour code 


6 


M 


000000? 


Pre-defined scrambling 








000001 2 


Operator defined scrambling, for cell 
identifier and scrambling process as defined 
in clause 8 








...etc. 


...etc. 








1111112 


Operator defined scrambling, for cell 
identifier and scrambling process as defined 
in clause 8 


Timeslot number 


2 


M 


00 2 


Timeslot 1 








01? 


Timeslot 2 








10? 


Timeslot 3 








11? 


Timeslot 4 


Frame number 


5 


M 


00000? 


Reserved 








00001? 


Frame 1 








...etc. 


...etc. 








01010? 


Frame 18 








others 


Reserved 


Multiframe number 


6 


M 


000000? 


Reserved 








000001? 


Multiframe 1 








...etc. 


...etc. 








111100? 


Multiframe 60 








others 


Reserved 


Sharing mode 


2 


M 


00? 


Continuous transmission 






01? 


Carrier Sharing 








10 2 


MCCH sharing 








11? 


Traffic carrier sharing 


TS reserved frames 


3 


M 


000? 


1 frame reserved/2 multiframes 








001? 


2 frames reserved/2 multiframes 








010? 


3 frames reserved/2 multiframes 








011? 


4 frames reserved/2 multiframes 








100? 


6 frames reserved/2 multiframes 








101? 


9 frames reserved/2 multiframes 








110 2 


12 frames reserved/2 multiframes 








111? 


18 frames reserved/2 multiframes 


U-plane DTX 


1 


M 


0 


Discontinuous U-plane transmission is not 
allowed 








1 


Discontinuous U-plane transmission is 
allowed 


Frame 18 extension 


1 


M 


0 


No frame 18 extension 








1 


Frame 18 extension allowed 


Reserved 


1 


M 


0 


Default value 








1 


Not used in this version of the ETS 


TM-SDU (MLE data) 


29 


M 




as defined in clause 18 



Page 384 

ETS 300 392-2: March 1996 

21 .4.4.3 ACCESS-DEFINE 

The ACCESS-DEFINE PDU may be sent by the BS using a half slot or full slot on the downlink (SCH/HD 
or SCH/F) or on downlink STCH. It defines the random access parameters for the specified access code 
and its contents are given in table 336. 



Table 336: Access define element contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


10? 


Broadcast PDU 


Broadcast type 


2 


M 


01 2 


ACCESS-DEFINE PDU 


Common or assigned 
control channel flag 


1 


M 


0 


ACCESS-DEFINE applies to common ch 1 


1 


ACCESS-DEFINE applies to assigned en 1 


Access code 


2 


M 


00? 


Access code A 


01? 


Access code B 


102 


Access code C 


11? 


Access code D 


IMM (immediate) 


4 


M 


0000? 


Always randomise 


0001? 


Randomise after IMM TDM A frames 


...etc. 


...etc. 


1110 2 


Randomise after IMM TDM A frames 


1111 2 


Immediate access allowed 


WT (waiting time) 


4 


M 


OOOO2 


Reserved 


0001 2 


Response within WT downlink opportunities 


...etc. 


...etc. 


1111? 


Response within WT downlink opportunities 


Nu (number of 
random access 
transmissions on 
uplink) 


4 


M 


OOOO2 


No random access transmission allowed 


0001 2 


1 random access transmission allowed 


...etc. 


...etc. 


1111? 


15 random access transmissions allowed 


Frame length factor 


1 


M 


0 


Multiply base frame length by 1 


1 


Multiply base frame length by 4 


Timeslot pointer 


4 


M 


OOOO2 


Same as downlink slot assignment 


0001 2 


Timeslot 4 


001 0 2 


Timeslot bit map 


...etc. 


...etc. 


1110? 


Timeslot bit map 


1111? 


All four timeslots 


Minimum priority 


3 


M 


000? 


Priority 0 (lowest) 


...etc. 


...etc. 


111? 


Priority 7 (highest) 


Optional field flag 


2 


M 


00? 


None 


01? 


Subscriber class bit map 


10? 


GSSI 


11 2 


Reserved, see note 


Subscriber class bitmap 


16 


C 




as defined in clause 18 


GSSI 


24 


C 




Group short subscriber identity 


NOTE: Values 00? and 1 1 ? indicate that there is no added optional field. 



The definition of the various random access parameters is as follows: 



common or assigned flag: 

this indicates whether the ACCESS-DEFINE PDU applies to MS using the channel for 
common control or MS using it for assigned control; 

access code: 

this is used in the ACCESS-ASSIGN message to control access for a subdivision of the MS 
population; 
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IMM: 

this is the Aloha parameter defining when the MS may use the first valid access opportunity 
for its first random access transmission. This time is counted in terms of TDMA frames; 

WT: 

this is the Aloha parameter defining the waiting time before the MS decides to initiate an 
access re-try. This time is counted in terms of BS downlink signalling opportunities for this 
control channel; 

Nu: 

this is the Aloha parameter giving the number of random access transmissions a MS may 
send before abandoning the random access attempt; 

frame length factor: 

this is a multiplying factor applied to the base frame length contained in the ACCESS- 
ASSIGN message; 

timeslot pointer: 

this is a pointer to where the ACCESS-ASSIGN message shall be monitored. 
21 .4.5 TMD-SAP: MAC PDU structure for U-plane signalling 

The MAC-U-SIGNAL PDU shall be used on the uplink and downlink for sending U-plane signalling 
information. This PDU shall only be sent using the STCH in conjunction with an established circuit mode. 
Its contents are shown in table 337. 



Table 337: MAC-U-SIGNAL PDU contents 



Information element 


Length 


Type 


Value 


Remark 


PDU type 


2 


M 


112 


MAC-U-SIGNAL 


Second half slot 


1 


M 


0 


Second half slot not stolen 


stolen flag 






1 


Second half slot stolen 


TM-SDU 


121 


M 







The first two bits of the MAC header shall distinguish this PDU as a MAC-U-SIGNAL PDU. The second 
half slot stolen flag shall indicate whether the second half of the full slot is also stolen. If the second half is 
stolen it may contain U-plane or C-plane signalling as indicated by the MAC header. The SDU contains 
the user information which is received from the U-plane for transmission in this PDU or passed to the 
U-plane on receipt of this PDU. It shall be the responsibility of the user application at the higher layer to 
specify the meaning of the contents of the TM-SDU. The TM-SDU length shall always be 121 bits. If the 
user application requires fewer bits, it is the responsibility of that application to insert filler bits to ensure a 
121 bit TM-SDU length. 

If MAC-U-SIGNAL is sent in the second half of a full slot, the second half slot stolen flag shall still be 
present but its content shall be ignored. 

21 .4.6 TMD-SAP: MAC PDU structure for U-plane traffic 

The MAC-TRAFFIC PDU shall be used for sending U-plane traffic data on the uplink and downlink using 
TCH/S, TCH/7,2, TCH/4,8 or TCH/2,4. This PDU has no header and all capacity shall be devoted to traffic 
information passed to and from the U-plane. When the MAC is in traffic mode, this PDU type shall be 
assumed unless the slot flag indicates the presence of the STCH. 

When stealing does not occur, the MAC-TRAFFIC PDU shall occupy the full slot. If stealing occurs, and 
only the first half of the slot is stolen, the MAC-TRAFFIC PDU shall occupy the second half of the slot. 
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NOTE: This is only true in the case of speech MAC-TRAFFIC PDUs. 
21 .4.7 MAC PDU structure for access assignment broadcast 

The ACCESS-ASSIGN PDU is generated by the MAC and so shall not contain any TM-SDU from the 
layer above. The ACCESS-ASSIGN PDU shall use the AACH which is mapped onto the broadcast block 
and shall be sent by the BS on every downlink slot (refer to clause 9). This PDU shall be used to convey 
information about the downlink slot in which it appears and also the access rights for the corresponding 
(same-numbered) uplink slot. Its contents shall be dependent on whether it is being sent in frames 1-17 or 
in frame 18. Tables 338 and 339 show the contents of this PDU. 



Table 338: ACCESS-ASSIGN PDU contents for frames 1 to 17 



Information element 


Length 


Type 


Value 


Remark 


Header 


2 


M 


00 2 


Downlink usage - common control 
Uplink access rights - common only 


01 2 


Downlink usage - defined by field 1 
Uplink access rights - common & assigned 


10 2 


Downlink usage - defined by field 1 
Uplink access rights - assigned only 


11 2 


Downlink usage- defined by field 1 
Uplink access rights - defined by field 2 


Field 1 


6 


M 


note 


Header 00 2 : Access field 1 
Header 01 2 : Downlink usage marker 
Header 10 2 : Downlink usage marker 
Header 11?: Downlink usage marker 


Field 2 


6 


M 


note 


Header 00 2 : Access field 2 
Header 01 2 : Access field 
Header 10 2 : Access field 
Header 11?: Uplink usage marker 


NOTE: Content and values of the fields 1 and 2 depends on the Header values as defined in the 
Remarks column. 



Possible values for downlink usage marker in the field 1 : 



Reserved UMr 00001 1 2 

Common control UMc 00001 0 2 

Assigned control UMa 000001 2 

Unallocated UMx 000000 2 

TrafficUMt others, (see note) 

Possible values for uplink usage marker in the field 2: 

Unallocated UMx 000000 2 

TrafficUMt others, (see note) 

NOTE: The values of the UMr, UMc, UMa and UMx are excluded. 

UMc, UMa and UMx are pre-set usage markers which shall not be assigned as traffic usage markers. UMt 
is the traffic usage marker, assigned in the MAC-RESOURCE PDU which allocated the channel. 

Access field 1 shall indicate the access restrictions for the first subslot of the corresponding uplink slot. 
Access field 2 shall indicate the access restrictions for the second subslot of the corresponding uplink slot. 
Access field (with no following number) shall indicate the access restrictions for both subslots of the 
corresponding uplink slot. The definition of the access field contents is given in the access field element 
definition. 
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Table 339: ACCESS-ASSIGN PDU contents for frame 18 



Information element 


Length 


Type 


Value 


Remark 


Header 


2 


M 


00? 


Uplink access rights: common only 


01? 


Uplink access rights: common & assigned 


10? 


Uplink access rights: assigned only 


11? 


Uplink access rights: common & assigned 


Field 1 


6 


M 


note 


Header 00: Access field 1 
Header 01 : Access field 1 
Header 10: Access field 1 
Header 1 1 : Traffic usage marker (UMt) 


Field 2 


6 


M 


note 


Header 00: Access field 2 
Header 01 : Access field 2 
Header 10: Access field 2 
Header 1 1 : Access field 


NOTE: Content and values of the fields 1 and 2 depends on the Header values as defined in the 
Remarks column. 



21 .5 MAC elements 



The following subclauses describe the elements which are referred to in the MAC PDU descriptions. 
21.5.1 Access field 



Table 340: Access field element contents 



Information element 


Length 


Type 


Value 


Remark 


Access code 


2 


M 


00? 


Access code A 








01? 


Access code B 








10? 


Access code C 








11 2 


Access code D 


Base frame-length 


4 


M 


0000? 


Reserved subslot 






0001? 


CLCH subslot 








0010? 


Ongoing frame 








0011? 


1 subslot 








0100? 


2 subslots 








0101? 


3 subslots 








0110? 


4 subslots 








0111? 


5 subslots 








1000? 


6 subslots 








1001? 


8 subslots 








1010? 


10 subslots 








1011? 


12 subslots 








1100? 


16 subslots 








1101? 


20 subslots 








1110? 


24 subslots 








1111? 


32 subslots 
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21 .5.2 Channel allocation 



Table 341: Channel allocation element contents 



Information element 


Length 


Type 


Value 


Remark 


Allocation type 


2 


M 


00p 


Replace current channel with specified channel 


01? 


Additional channel allocation 


10 2 


Quit current channel and go to specified 
channel 


11 2 


Replace current channel with specified channel 
plus carrier specific signalling channel in slot 1 


Timeslot assigned 


4 


M 


0000 2 


Go to appropriate MCCH downlink slot (MCCH 
or common SCCH) 


0001 ? 


Timeslot number 4 


0010?. 


Timeslot number bit map 


...etc. 


...etc. 


1110 ? 


Timeslot bit map 


1111? 


All 4 timeslots 


Up/downlink 
assigned 


2 


M 


00? 


Reserved 


01? 


Downlink only 


10? 


Uplink only 


11? 


Both uplink and downlink 


CLCH permission 


1 


M 


0 


No immediate CLCH permission 


1 


Immediate CLCH permission 


Cell change flag 


1 


M 


0 


No ceil change 


1 


Cell change 


Carrier number 


12 


M 




Carrier freguency number 


Extended carrier 
numbering flag 


1 


M 


0 


No extended carrier numbering 


1 


Extended carrier numbering 


Freguency band 


4 


C 




Provision for different freguency bands 


Offset 


2 


C 




Provision for different offsets 


Duplex spacing 


3 


c 




Provision for different duplex spacing 


Reverse operation 


1 


c 


0 


Normal 


1 


Reverse 


Monitoring pattern 
(see clause 9) 


2 


M 


00? 


No monitoring pattern 


01? 


One monitoring pattern 


10? 


Two monitoring patterns 


11? 


Three monitoring patterns 


Frame 18 
monitoring pattern 


2 


C 


00? 


No monitoring pattern 


01? 


One monitoring pattern 


10? 


Two monitoring patterns 


11 2 


Three monitoring patterns 



The CLCH permission field shall indicate to the MS whether the first sub-slot on the assigned channel 
shall be available for linearization purposes. The MS need not examine the AACH field in order to use 
CLCH if permission is given in the channel allocation field. 



The carrier frequency shall be defined by the following elements: 
carrier number; 

extended carrier numbering flag; 

frequency band; 

offset; 

duplex spacing; 



reverse operation. 
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The extended numbering flag indicates whether the carrier frequency specification includes the frequency 
band, offset, duplex spacing and reverse operation fields. If this field indicates no extended numbering, 
then the MS shall assume the same frequency band, offset, duplex spacing and reverse operation values 
as contained in the SYSINFO PDU. The actual carrier frequency shall then be calculated using the same 
equations as defined for the main carrier frequency calculation in the SYSINFO PDU description (but with 
the allocated "carrier number" replacing "main carrier"). 

The monitoring pattern field applies to a transmitting MS on an assigned channel and it indicates which 
downlink slots shall be monitored while transmitting traffic. If one monitoring pattern is assigned, 
monitoring pattern number one as defined in clause 9 shall be used. If two monitoring patterns are 
assigned, monitoring pattern numbers one and two as defined in clause 9 shall be used. If three 
monitoring patterns are assigned, monitoring pattern numbers one, two and three as defined in clause 9 
shall be used. 

If no monitoring pattern is assigned, then the frame 18 monitoring pattern field shall be included to indicate 
which monitoring patterns shall be followed for frame 18. One, two or three monitoring patterns can be 
assigned for frame 18 in the same way as described before. So, for example, if one monitoring pattern is 
assigned, the MS shall monitor frame 18 if Multiframe Number mod 3 = 0; if two monitoring patterns are 
assigned, the MS shall monitor frame 18 if Multiframe Number mod 3 = "0"or 2. 

21-5.3 Power control 



Table 342: Power control element contents 



Information element 


Length 


Type 


Value 


Remark 


Power control 


4 


M 


0000? 


No change in power 








0001 2 


Increase power by 1 step 








001 Op 


Increase power by 2 steps 








0011 2 


Increase power by 3 steps 








01002 


Increase power by 4 steps 








01 01 2 


Increase power by 5 steps 








01102 


Increase power by 6 steps 








01112 


Maximum path delay exceeded 








10002 


Revert to open loop power control 








10012 


Decrease power by 1 step 








10102 


Decrease power by 2 steps 








10112 


Decrease power by 3 steps 








11002 


Decrease power by 4 steps 








1101? 


Decrease power by 5 steps 








1110? 


Decrease power by 6 steps 








1111? 


Radio uplink failure 



The power control step size is 5 dBm as defined in clause 6. The power shall not be decreased below the 
minimum power step value of 1 5 dBm or above the maximum power step for that MS class. 
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21 .5.4 Reservation requirement 



Table 343: Reservation requirement element contents 



Information element 


Length 


Type 


Value 


Remark 


Reservation 


4 


M 


0000 9 


1 subslot required 


requirement 






0001 2 


1 slot required 






001 0 2 


2 slots required 








0011 2 


3 slots required 








01002 


4 slots required 








0101? 


5 slots required 








01102 


6 slots required 








01112 


8 slots required 








1000? 


10 slots required 








1001? 


13 slots required 








10102 


17 slots required 








1011? 


24 slots required 








11002 


34 slots required 








11012 


51 slots required 








1110? 


68 slots required 








1111? 


More than 68 slots required 



21 .5.5 TS_COMMON_FRAMES 



Table 344: TS_COMMON_FRAMES element contents 



Information element 


Length 


Type 


Value 


Remark 


Frame 1 


1 


M 


0 


Not a common frame 








1 


Common frame 


Frame 2 


1 


M 


0 


Not a common frame 








1 


Common frame 


...etc. 


...etc. 


...etc. 


0 


...etc. 








1 


...etc. 


Frame 18 


1 


M 


0 


Not a common frame 








1 


Common frame 


Reserved 


1 


M 


0 


Default value 








1 


Not used in this version of ETS 


Reserved 


1 


M 


0 


Default value 








1 


Not used in this version of ETS 
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21.5.6 Slot granting 



Table 345: Slot granting element contents 



Information element 


Length 


Type 


Value 


Remark 


Capacity Allocation 


4 


M 


0000? 


First subslot allocated 






0001 ? 


1 slot allocated 








001 0 2 


2 slots allocated 








0011 2 


3 slots allocated 








0100 2 


4 slots allocated 








0101? 


5 slots allocated 








01102 


6 slots allocated 








01112 


8 slots allocated 








1000? 


10 slots allocated 








1001? 


13 slots allocated 








1010? 


17 slots allocated 








1011? 


24 slots allocated 








11002 


34 slots allocated 








11012 


51 slots allocated 








11102 


68 slots allocated 








1111? 


Second subslot allocated 


Granting delay 


4 


M 


0000? 


Capacity allocation at next opportunity 






0001 2 


Number of opportunities delay to capacity 
allocation 








...etc. 


...etc. 








1101 2 


Number of opportunities delay to capacity 
allocation 








1110? 


Allocation starts at first opportunity in frame 18 








1111? 


Wait for another slot granting message 



22 LLC protocol 

This clause is intended to be read together with the MAC protocol, clause 23. This clause describes the 
LLC sub-layer framing functions for the V+D air interface. These sub-layer functions are closely integrated 
with the MAC sub-layer and together the MAC and LLC form the air interface layer 2, also called DLL. An 
overview of the DLL architecture can be found in clause 19. 



22.1 Overview of LLC 

See ETS 300 392-1 [11], clause 6 for general architecture and functional description. See clause 19 for 
DLL architecture. See clause 20 for service description and SAPs. See clause 21 for PDU description. 

The LLC procedures defined in this ETS are applicable to the MS unless indicated to be valid for the BS. 
The LLC procedures used in the BS shall be compatible with the procedures described in this ETS. 

NOTE: In this subclause the word "shall" is used with service primitives for traceability reasons 
in the protocol model, but the primitives are not testable. 

22.1.1 LLC protocol 

LLC protocol for TETRA contains two entities, basic link and advanced link, both accessible via the same 
SAP TLA-SAP. Both the data links offer two different services, i.e. unacknowledged and acknowledged 
information transfer mechanisms. The basic link is available whenever the MS is synchronised to a BS. 
The advanced link provides a better quality of service than the basic link and uses a connection on 
demand. The basic link offers an option for extended FCS to minimise the number of undetected 
erroneous messages. The same frame check sequence is always used on the advanced link. 
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The MS LLC can support up to four advanced links per service, numbered from one to four. The various 
link services will be discriminated locally by a different end-point identifier. In the LLC itself, the distinct 
PDU types shall differentiate both between a basic and an advanced link and unacknowledged and 
acknowledged service (see clause 21). There shall be a unique correspondence between the end-point 
identifier and the timeslot or timeslots used in the MAC. End-point identifiers in the peer entity may be 
independent of these local identifiers. For a certain link number, there can exist one acknowledged service 
or one unacknowledged service or both. Unacknowledged and acknowledged services are set-up and 
disconnected independently of each other. If they coexist on the same link number, they shall use the 
same physical allocation (same time-slots). In this case there is only one basic link associated with both 
the advanced link services. 

There is one basic link per each advanced link and each circuit mode service, when an ACCH is available. 
The number of timeslots each basic link may use, is the same as the number of timeslots of the 
corresponding advanced link or circuit mode service. 

The transfer mode of a LLC link is independent of the modes of the other LLC links forming a network 
layer connection. As an example, a point-to-multipoint call from a MS to multiple MSs may use an 
advanced LLC link from the sending MS to the BS and the unacknowledged basic LLC link from the BS to 
the receiving MSs. 

This LLC protocol for TETRA operates using PDUs. The PDUs are described in clause 21. The basic link 
LLC PDU sizes are independent of the MAC layer block sizes, because MAC can fragment a LLC PDU if 
needed. The advanced link LLC protocol is constrained by the segment sizes matching the available room 
in MAC blocks. The data link operation may use the knowledge of the multiframe structure for 
transmission optimisation. 

22.1 .2 Communication routes of the LLC model 

Figure 101 shows relations of the MS LLC layer protocols in the TETRA protocol stack. The service user 
selects service and signal route by selecting endpoint identifier at the TLA-SAP. There is also a LLC flow 
control provided between LLC peer entities on the advanced link. The flow control is accessible to the LLC 
service user via a MLE-LLC control route. 
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TL_DATA_conf irm , 
TL_DATA_indication, 
TL_REPORT_indication, 
TL UNITDATAJndication 



TLA SAP route_bl 



TL_D ATA_req uest, 
TL_DATA_response. 
TL CANCEL.request, 
TL~U N IT D AT A_request; 



TL CONNECTjndication, 

TLlCONNECT_confirm, 

TL_DATA_confirm, 

TL_DATA_indication t 

TL DISCONNECT indication 

TL DISCONNECT.confirm, 

TL_REPORT indication, 

TL_UNITDATA_indication; ^ 



TLA_SAP_route_al 



TL_CANCEL_request, 
TL_CONNECT_request, 
TL_CO N N ECT_response , 
TL_DATA_request, 
TL_DISCONNECT_reques1 
TL_UNITDATA_request; 



Control_route_ 
MLE_LLC 



FLO W_N OT_R EADY.l 
FLOW.READY; J 



LLC_MS 



MAC.READY, 

TMA_REPORT_indication, 

TMA_UNITDATA_indication 



TMA_SAP_route 



DATA_IN_BUFFER, 
TMA_CANCEL_request, 
TM A_U N ITD ATA_req uest; 







Radio _path 




MAC_MS 


BS 


rr-n 



Figure 101: LLC relations 
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TL_DATA__ 
confirm, 
TL_DATA_ 
indication, 

TL_REPORT 

indication, 

TL_UNITDATA_ 

indication; 



TLA_SAP_ 
route bl 



TL_CANCEL 

request, 
TL_DATA_ 
request, 
TL_DATA_ 
response, 
TL_UNITDATA_ 
request; 



TL_DATA 

confirm, 
TL_REPORT_. 
indication; 



Route al TX 



TL_DATA 

request, 
TL_CANCEL_ 
request, 
TL_UN ITD ATA_ 
request; 



TL_CONNECT 

indication, 

TL_CONNECT 

confirm, 

TL_D!SCONNECT. 
indication, 

TL_REPORT 

indication; 



Route 

al main 



TL_CONNECT 

request, 

TL_CONNECT 

response, 

TL DISCONNECT. 



request; 



Control 

route 

MLEJ.LC 

FfLO W_NOT_R EAD Y ,1 
[FLOW.READY; J 



1,1 



AL MAIN 



Control_ 
route_al 



Start 
Stop. 



LTX.l 

»_TX;J 



1.4 



BL_LLC_MS 



1,4 



AL TX 



BL_ACK, 

BL.DATA, 

BL.ADATA, 

BLJJDATA, 

MAC READY, 

TMA_REPORT_ 

indication; 

TX_RX_ 
route_bl 

BU.ACK, 
BL.DATA, 
BL.ADATA, 
BLJJDATA, 
DATA_IN_BUFFER , 



AL_ACK, 
AL_RNR, 
MAC_READY, 

TMA_REPORT 

indication; 



TX route al 



AL.DATA, 
AL_DATA_AR, 
AL.RNAL, 
AL_FINAL_AR, 
DATA_IN_BUFFER 



Tal.setup] 

[aL_DISC; j 



Main route al 



AL_SETUP, 
AL_DISC, 

DATA_IN_BUFFER; 



Control_ 
route_al 



Start_RX, 
Stop_RX; 



[tl_dataJ 

I indication; J 



Route_al_RX 



ItL_UNITDATA J 
[indication; j 

Route 

al.UNACK 



1,4 



AL RX 



Al^DATA, 

al_data_ar, 

AL_FINAL. 
AL_FINAL_AR, 
MAC_ READY; 



RX route_al 



AU.ACK, 
AL_RNR, 
DATA_IN_BUFFER; 



1,4 

AL.UNACK 



[al.udata] 

|_AL_UFINAy 



UNACK_ 
route_al 



1,1 



Formatter 



MAC_R EADY(s ize) , 
TMA^REPORT indication, 
TMA_UNITDATA_indication 



TMA_SAP_route 

[DATA_IN_BUFFER(size, prority)] 
[TM A_U N ITD AT A_request; J 



Figure 102: LLC protocol structure 



Figure 102 shows the internal structure of the LLC presenting the basic and the advanced links and layer 
composition of various processes. 
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The basic link protocol uses the following routes: 

the TLA-SAP route bl corresponds to the TLA-SAP; 

the TX-RX route bl corresponds to TMA-SAP showing LLC PDUs. 
The advanced link protocol uses following routes: 

the Route al main corresponds to the TLA-SAP for the connection set-up and disconnection; 

the Route al TX corresponds to the TLA-SAP for acknowledged data transmission; 

the Route al RX corresponds to the TLA-SAP for acknowledged data reception; 

the Control Route MLE-LLC corresponds to the TLA-SAP for flow control purposes; 

the Main route al corresponds to TMA-SAP and carries LLC PDUs for connection set-up and 
disconnection; 

the TX route al corresponds to TMA-SAP and carries LLC PDUs and control signals, which are 
used in acknowledged data transmission; 

the RX route al corresponds to TMA-SAP and carries LLC PDUs and control signals, which are 
used in acknowledged data reception; 

the Route al UNACK corresponds to TLA-SAP for unacknowledged service; 

the UNACK route al corresponds to TMA-SAP and carries LLC unacknowledged service PDUs; 

the Control route al carries local control of the advanced links. 

Information exchange between LLC and MAC: 

the TMA-SAP route corresponds to the TMA-SAP, and carries primitives and local information 
exchange. 

22.2 Scenarios on LLC procedures 

This subclause describes scenarios for normal TL-SDU transfer cases. For clarity many details such as 
TL-REPORT indications are not included into message sequence diagrams. 

22.2.1 Basic link mode 

The basic link is available for information transfer whenever the MS is synchronised to a BS. There are 
two data transfer modes, acknowledged and unacknowledged PDU transfer. The acknowledged data 
transfer can be used for point-to-point communication and the unacknowledged data transfer can be used 
both for point-to-multipoint and point-to-point communication. 

22.2.1 .1 Acknowledged PDU transfer (BL-D ATA + BL-ACK) 

Figure 103 and figure 104 show the transfer of information when the basic link is used. This protocol 
supports a message pair exchange based on primitives TL-DATA request and TL-DATA indication in one 
direction and on primitives TL-DATA response and TL-DATA confirm in the other direction as shown in 
figure 103. The TL-SDU from the left hand side entity is transmitted in the BL-DATA PDU. The TL-SDU in 
the TL-DATA response primitive from the right hand side LLC to the left hand side LLC is transferred in 
the BL-ACK PDU. That TL-SDU is not acknowledged directly with an explicit transfer of an 
acknowledgement PDU (though the left hand side entity may retransmit its BL-DATA PDU if it does not 
receive the BL-ACK PDU). Each BL-DATA PDU carries a TL-SDU number N(S), which indicates the 
number of the present BL-DATA PDU in that direction of information flow. The peer entity acknowledges 
the successful reception of this BL-DATA PDU by sending the same TL-SDU number N(R) in the 
acknowledgement BL-ACK PDU, see figure 104 for the PDU exchange. 
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NOTE: This protocol uses in the acknowledgement message the same message number as in 
the received data message in contrary to most HDLC protocols, which typically rely on 
a continuous message exchange and use in the acknowledgement the next expected 
message number. 

TL-DATA TL-DATA TL-DATA TL-DATA 

request confirm response indication 





/ 

/ 


\ 


^ BL-ACK 




/ 

/ 


\ 


LLC 




LLC 


^tt: ) 



BL-DATA 



Figure 103: Basic link PDU exchange with acknowledgement carrying a layer 3 message 



LLC A 
TL-DATA request 



TL-DATA confirm 



BL-DATA 



BL-ACK 



LLC B 



TL-DATA indication 
TL-DATA response 



note 



NOTE: BL-ACK includes the response data from the service user. 

Figure 104: Basic link data transfer and acknowledgement with a layer 3 message 

In the previous scenario there was a layer 3 TL-DATA response available, when the BL-ACK PDU was 
sent. If there is no layer 3 information available, then a short acknowledgement PDU is sent as shown in 
figure 105 and figure 106. The LLC assumes that the LLC service user will normally provide a TL-DATA 
response to the TL-DATA indication before the LLC and MAC has the next opportunity to send the 
BL-ACK PDU as shown above. If the TL-DATA response is offered to the LLC after the sending of the 
BL-ACK PDU, then the LLC sends it as if it were a TL-DATA request using a BL-DATA PDU, which is 
presented to the receiving service user as a TL-DATA indication primitive and will be confirmed, see the 
second set of primitives in figure 105 and figure 106. 



TL-DATA 
request 



TL-DATA 
confirm 
TL-DATA 
indication 



LLC 



TL-DATA 
response 
TL-DATA 
request 



BL-ACK 
BL-DATA 



BL-ACK 
BL-DATA 



TL-DATA 
indication 
TL-DATA 
confirm 



LLC 



Figure 105: Basic link PDU exchange with LLC acknowledgement with a delayed response 
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LLC A 
TL-DATA request 



TL-DATA confirm 
TL-DATA indication 



BL-DATA 




LLC B 



TL-DATA indication 



TL-DATA response 



TL-DATA confirm 



note 1 
note 2 

note 2 



NOTE 1 : When there is no TL-DATA response available, then LLC sends an acknowledgement 
without data. 

NOTE 2: The LLC transfers a delayed TL-SDU in the TL-DATA response primitive using normal 
acknowledged service as if it were a TL-DATA request and a successful transfer will be 
confirmed with a TL-DATA confirm primitive to the service user. 

Figure 106: Basic link data transfer and acknowledgement with a delayed layer 3 response 

The basic link also allows concurrent data transfer in both directions independent of each other as shown 
generally in figure 107 and as an example in figure 108. A TL-DATA request is sent in a BL-DATA PDU 
from the LLC A. The LLC B may combine the acknowledgement and the user data from a TL-DATA 
request into a BL-ADATA PDU. At the LLC A receiver the acknowledgement will be delivered to the 
service user in a TL-DATA confirm and the user data is delivered in an independent TL-DATA indication. 
The example continues with the second TL-DATA request and with the corresponding combined 
BL-ADATA PDU. To the resulting TL-DATA indication the LLC B responds with a TL-DATA response 
primitive and the user data is sent in a BL-ACK PDU. This is delivered to the service user in a TL-DATA 
confirm primitive and there is no explicit acknowledgement sent to that data. The next user data PDU from 
the LLC A will be a BL-DATA PDU and it is in this example acknowledged by a BL-ACK PDU without data. 
If the user does not want to send a response but an independent data, see figure 108 note 1 f then 
a TL-DATA request primitive is used and the LLC will acknowledge the received data either with 
a BL-ACK or with a BL-ADATA PDU. In figure 107 there are two sets of service primitives, the upper and 
lower are used in the information flow from left to right and from right to left respectively. 



TL-DATA 
request 

TL-DATA 
response 



TL-DATA 
confirm 

TL-DATA 
indication 



TL-DATA 
response 

TL-DATA 
request 



LLC 



BL-ACK 
BL-DATA, BL-ADATA 



BL-DATA, BL-ADATA 
BL-ACK 



TL-DATA 
indication 

TL-DATA 
confirm 
/N 



LLC 



Figure 107: Concurrent independent message exchange in both directions 
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LLC A 
TL-DATA request 



TL-DATA confirm 
TL-DATA indication 
TL-DATA request 



TL-DATA confirm 
TL-DATA request 



TL-DATA confirm 



BL-DATA 



BL-ADATA 



BL-ADATA 



BL-ACK 



BL-DATA 



BL-ACK 



LLC B 



TL-DATA indication 
TL-DATA request 



TL-DATA confirm 
TL-DATA indication 
TL-DATA response 



TL-DATA indication 



note 1 



note 2 



NOTE 1 : Service user offers a data request instead of a response. 

NOTE 2: There may be also a data response, which is carried in BL-ACK PDU and will not be 
acknowledged directly. 

Figure 108: Concurrent independent message exchange In both directions 

The LLC sends reports, or reports on the progress of data sending, to the service user based on 
information from MAC layer. Those reports will be explained in the protocol description and are not 
presented here. 

In this protocol, a single TL-SDU, in a BL-DATA or BL-ADATA PDU, is sent and acknowledged at a time 
and the window size is equal to 1 . There is no peer-to-peer flow control mechanism for the basic link. 



22.2.1.2 



Unacknowledged data transfer (BL-UDATA PDU) 



Unacknowledged mode of operation is mainly used to address a group of MSs (point-to-multipoint) as 
shown in figure 109 and figure 110, where the BL-UDATA PDU is used to transfer information. No 
responses nor acknowledgements are expected to a BL-UDATA PDU. The sending LLC entity may repeat 
a UDATA PDU several times to increase the probability of a correct reception. The receiving protocol does 
not suppress received duplicates. The LLC may send a report or reports on the progress of data sending 
to the service user. 

The BL-UDATA PDU may be used also for sending data from a MS to the base station. 



TL-UNITDATA 
indication 



TL-UNITDATA 
request 



LLC 



If 



BL-UDATA 
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Figure 109: PDU exchange in unacknowledged mode 
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LLC A 



TL-DATA indication 



BL-UDATA 



LLC B 

TL-DATA request 



Figure 110: Basic link data transfer in unacknowledged mode 
22.2.1 .3 Unacknowledged data transfer with presence indication (BL-DATA + BL-ACK PDU) 

This subclause describes how a BS may implement presence checking in group call establishment. 

This operation mode of the BS allows sending of unacknowledged data and requesting a low level 
presence indication from one or more recipient MS. The presence indication message carries only 
indication that at least one MS has received the message correctly and should not contain any other 
useful information, see figure 111 and figure 112. In response to the TL-DATA request with a presence 
indication parameter the base station sends a normal BL-DATA PDU and waits for an answer from one or 
more MSs. The MS LLC sends a normal acknowledgement, which is detected in the BS without actually 
decoding it especially if many MSs have answered at the same time. The BS LLC does not re-send the 
BL-DATA PDU to get back a de-codeable BL-ACK PDU, but it may send BL-DATA PDU more than once 
for more reliable data transfer. 

TL-DATA TL-DATA TL-DATA 

indication request confirm 







y BL-DATA 
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LLC 
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Figure 111: Basic link data transfer with presence indication 

MS LLC BS LLC 

TL-DATA request TL-DATA request primitive 

with presence request 



TL-DATA confirm No user data 



TL-DATA indication 




Figure 112: Basic link data transfer with presence indication 
22.2.2 Advanced link 

The advanced link provides two data transfer services, i.e. acknowledged and unacknowledged PDU 
transfer. The acknowledged data transfer can be used for point-to-point communication and the 
unacknowledged data transfer is intended to be used for point-to-multipoint communication, but may also 
be used for point-to-point information transfer on the downlink. Both services of the advanced link need to 
be set-up before they can be utilised. The life of an advanced link comprises a connection set-up, data 
transfer and connection release. The life time of an advanced link may be limited or unlimited provided 
that the MS communicates with the same BS. 

The advanced link protocol can send multiple TL-SDUs before an acknowledgement shall be sent or is 
received. The transmitting station may send up to N.272 TL-SDUs before requesting and receiving a 
specific acknowledgement. The LLC may re-send TL-SDUs under a request from the receiving LLC entity 
or due to a lack of an acknowledgement. 

The advanced link segments TL-SDUs which are too long to be carried in one MAC transmission unit 
(MAC block), and applies automatic selective re-transmission to badly received segments. 
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22.2.2.1 Setting up the connection mode (AL-SETUP PDU) 

The advanced LLC link connection for acknowledged service shall be negotiated between the two LLC 
entities as described in figures 113 to 118 inclusive. Either the MS or BS may initiate the advanced link 
connection set-up. A new connection set-up during an already existing connection overrides it and 
performs a link reset. The resulting connection mode advanced link may coexist with an unacknowledged 
advanced link, refer to subclause 22.2.2.2. 



The connection request contains all parameters for negotiation: 
the maximum length of the TL-SDU N.271 ; 

the allowed number of TL-SDU re-transmissions before LLC gives up N.273; 



the LLC TL-SDU window size N.272; 



the number of re-transmissions of a segment N.274 before LLC reports an error to the service user; 



the number of timeslots used per a TDM A frame N.264; 



the number of advanced link N.261 and the requested mean value for the data transfer throughput, 
(see note). 

The negotiation uses AL-SETUP PDUs. 

NOTE: These constants are part of the quality of service negotiation and are transmitted to the 
peer side. Depending on the mobile class and base station services, the peer entity 
may wish to respond with a lower quality of service or even refuse the connection set- 
up. 

The resulting connection will support two-way exchange of information between the peer LLC entities. 



TL-CONNECT 
request 



TL-CONNECT TL-CONNECT TL-CONNECT 
confirm response ^ indication 



AL-SETUP 



LLC 



AL-SETUP 
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Figure 113: PDU setting up the advanced link 
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Figure 114: Advanced link set-up 
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LLC A 



TL-CONNECT indication 
TL-CONNECT request 



LLC B 

AL-SETUP TL-CONNECT request 



AL-SETUP note 1 

TL-CONNECT indication note 1 
AL-SETUP TL-CONNECT response note 2 



TL-CONNECT confirm 



NOTE 1 : Proposed QoS is not acceptable and a new QoS is proposed. The service negotiation may 
be performed as an direct negotiation between the LLC entities. 

NOTE 2: The lower QoS is accepted 



Figure 115: Advanced link set-up to a lower quality of service 
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TL-CONNECT request 
TL-CONNECT confirm 
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Figure 116: Simultaneous advanced link set-up 
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TL-CONNECT request 

TL-CONNECT indication 
TL-CONNECT response 



AL-SETUP 

~AL-SETUP" 
AL-SETUP 



LLC B 

TL-CONNECT request 
TL-CONNECT indication 



TL-CONNECT confirm 



Different QoS 

note 1 
note 2 



NOTE 1 : TL-CONNECT primitive is shown as an indication due to differences in QoS. 
NOTE 2: The LLC A confirms the lower QoS before the LLC B sends a new request. 

Figure 117: Simultaneous advanced link set-up with different QoS 
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Figure 118: Simultaneous advanced link set-up with different QoS 
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Figure 114 presents a message sequence diagram for an advanced link set-up, when the LLC B accepts 
the quality of service proposed by the LLC A. If the receiving station replies with a lower parameter setting, 
the transmitting station shall confirm those lower values and use these negotiated parameters for the 
advanced links shown in figure 115. A receiving station shall not reply with higher parameter setting. On 
the other hand, the receiving station may refuse the connection by returning a TL-DISCONNECT request 
(AL-DISC PDU). 

Figures 116 to 118 inclusive give examples of a set-up of the advanced link in special cases, when both 
LLC entities try to set-up a connection at the same time. 

The initial connect request shall set the TL-SDU and segment counters to the default values prior to the 
first transmission in both information flow directions. 

If the LLC cannot support the advanced link, it may send an AL-DISC PDU, see figure 119. 



LLC A LLC B 

TL-CONNECT request AL-SETUP 



TL-DISCONNECT indication 



AL-DISC 



TL-CONNECT indication 
(TL-DISCONNECT request) 



Figure 119: Unsupported service indication 

22.2.2.2 Setting up the unacknowledged transfer mode (AL-SETUP PDU) 

The advanced LLC link parameters shall be informed to the future participants of the unacknowledged 
transfer mode before the data transfer may commence successfully as described in figures 120 and 121. 
A new unacknowledged advanced link set-up during an already existing unacknowledged advanced link 
only modifies advanced link parameters without a reset functionality e.g. TL-SDU numbering shall 
continue without interruption. This set-up does not affect to the existing acknowledged advanced link 
service, if any, refer to subclause 22.2.2.1 . 

The set-up indication contains all relevant parameters for the unacknowledged advanced link: the 
maximum length of the TL-SDU N.271, the maximum number of TL-SDU re-transmissions N.282, the 
LLC TL-SDU window size N.281. The AL-SETUP PDU transmits these parameters. The AL-SETUP PDU 
may be sent several times (N.282+1 times) to increase the probability of correct reception. 

The resulting unacknowledged advanced link will support one-way exchange of information from the entity 
which sends the set-up information to the other peer LLC entities. The receiving entity may not be capable 
to conform to the selected parameters and may neglect the set-up. 
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Figure 120: Unacknowledged transfer mode set-up of the advanced link 
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MS LLC 



TL-CONNECT indication 



TL-CONNECT indication 



AL-SETUP 



AL-SETUP 



BS LLC 

TL-CONNECT request 



Figure 121 : Unacknowledged transfer mode set-up of the advanced link 

The unacknowledged advanced link entities shall set the TL-SDU and segments counters to the default 
values prior to the first transmission. 

A MS may start to receive unacknowledged advanced link transmissions also without receiving a 
AL-SETUP PDU, if it knows the allocated resource by other means. 

22.2.2.3 Data exchange in the connection mode (AL-DATA PDU) 

After the connection set-up the advanced LLC link is ready for a two-way exchange of information 
between the two peer LLC entities although actual information flow could be unidirectional and the other 
direction is used only for acknowledgements. The information flows in both directions (uplink and 
downlink) are independent of each other. Each AL-DATA PDU contains 2 numbers, the actual TL-SDU 
number N(S) and the absolute position of the segment inside the TL-SDU called segment sequence 
number S(S). The segment sequence number is used in selective re-transmission in the AL-ACK PDU. 

Data transfer in the advanced LLC link can be either unidirectional or bi-directional. In both cases data 
sending and data acknowledgements use same PDUs and protocol. In the first case, the transfer flow is 
shown in figures 122 and 123. In this example LLC A sends a segmented TL-SDU using AL-DATA PDUs 
and marks the last segment of the TL-SDU by using an AL-FINAL-AR PDU. In reply to the AL-FINAL-AR 
PDU the receiving LLC shall generate an acknowledgement using an AL-ACK PDU. The sending LLC 
informs the service user of the correct transfer of the layer 3 TL-DATA by issuing a TL-DATA confirm 
when a whole TL-SDU has been acknowledged. 

TL-DATA TL-DATA TL-DATA 
request confirm indication 



LLC 



AL-ACK 

AL-DATA, AL-DATA-AR 
AL-FINAL, AL-FINAL-AR 



-X. 



LLC 



Figure 122: PDU exchange in a unidirectional transfer 
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TL-DATA request 
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AL-ACK 



TL-DATA indication 



LLC A sends a long TL-SDU in 
segments 



The last segment is sent using 
AL-FINAL-AR 

LLC B acknowledges the 
TL-SDU 



TL-DATA confirm 

Figure 123: PDU exchange in a unidirectional transfer 

The sending LLC entity may request an acknowledgement from the peer entity at any time by using 
AL-DATA-AR or AL-FINAL-AR PDUs in place of the AL-DATA and AL-FINAL PDUs respectively. The 
sender may continue transmission of data without waiting for the requested acknowledgements, if allowed 
by the SDU window size. In figure 124 the LLC B asks an acknowledgement in the middle of sending a 
TL-SDU and later does not request an immediate acknowledgement to the complete TL-SDU. 

The receiver may send an AL-ACK PDU at any time in addition to the requested acknowledgements, see 
also subclause 22.2.2.7. 
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Figure 124: A longer PDU transfer 
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An example of bi-directional information transfer flow is shown in figures 125 and 126. The LLC A sends a 
message to the LLC B and the LLC B responds with another message. The LLC A starts the sending by a 
segmented TL-SDU using AL-DATA PDUs and marks the last segment of the TL-SDU by using 
AL-FINAL-AR PDU. The LLC B delivers the received TL-SDU to the service user as a TL-DATA indication 
primitive. The LLC B generates an acknowledgement AL-ACK PDU as a response to the AL-FINAL PDU. 
The acknowledged TL-SDU shall be indicated to the sending service user by a TL-DATA confirm primitive. 
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Figure 125: Bi-directional data transfer 
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AL-ACK 



note 1 



TL-DATA indication 



TL-DATA request 



note 2 



TL-DATA confirm 



NOTE 1 : The last segment is sent using AL-FINAL-AR. 

NOTE 2: LLC B sends a responding or independent TL-SDU. 

Figure 126: Bi-directional PDU transfer 

The LLC can accept more than one TL-SDU for sending before completing the transfer of the previous 
TL-SDU. The LLC may also modify the sending order of TL-SDUs depending on the priorities of those 
SDUs, but all already started transmissions needs to be completed before a new higher priority TL-SDU 
(non pre-emptive) may be transferred successfully. The LLC entity could also start sending of TL-SDUs at 
any time independently of the state of the other transfer direction. 

Pre-emptive priority transmissions across an advanced link may reset the link to get fast access, This 
action may corrupt the ongoing lower priority transmission. 
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22.2.2.4 Data exchange in the unacknowledged transfer mode (AL-UDATA PDU) 

After the unacknowledged data transfer set-up the advanced LLC link is ready for a one-way exchange of 
information. The service user data is transmitted in AL-UDATA PDUs. The AL-UDATA PDU contains two 
numbers: the actual TL-SDU number N(S) and the absolute position of the segment inside the TL-SDU 
called segment sequence number S(S). The segment sequence number is used in the rebuilding of the 
received TL-SDU from segments. The data transfer flow is shown in figures 127 and 128. In this example 
BS LLC sends a segmented TL-SDU using AL-UDATA PDUs and marks the last segment of the TL-SDU 
by using an AL-U FINAL PDU. The BS may send TL-SDU several times up to maximum re-transmissions 
(N.282) to increase the reception probability (and using the same segmentation for each repetition). 

The receiving LLC entity delivers TL-SDU to the service user in a TL-UNITDATA indication. The sending 
entity may inform the completion of all repetitions to the service user using an informal TL-UNITDATA 
confirm primitive. 
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Figure 127: PDU sending in a unidirectional transfer 
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TL-UNITDATA confirm MS received the whole 
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Figure 128: PDU sending in a unidirectional transfer 

The BS LLC may send repetitions of up to N.281 TL-SDUs in any order, but the oldest TL-SDU within that 
SDU-window with all repetitions shall be sent before a new TL-SDU may commence. The BS LLC may 
also modify the sending order of TL-SDUs depending on the priorities of those SDUs, but all already 
started transmissions needs to be completed or advanced link needs to be reset by setting up a new 
unacknowledged link, before a new higher priority TL-SDU may be started. 

The receiving entity may combine segments from multiple transmissions of the same TL-SDU in order to 
reassemble a complete TL-SDU. 
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22.2.2.5 



Window mechanism 



In the advanced link LLC protocol there is a window mechanism for TL-SDU transmissions. The window 
mechanism allows more than one TL-SDU and LLC data PDU respectively to be sent before required 
acknowledgements stop LLC transmissions. The TL-SDU window size N.272 is negotiated during the 
advanced link set-up, refer to subclause 22.2.2.1 . 

The receiving LLC entity may acknowledge each TL-SDU as soon as it is fully received, but the sending 
LLC entity may continue to send up to a total of N.272 TL-SDUs before receiving acknowledgements for 
the previous TL-SDUs. (For window size N.272=1, the receiving LLC entity acknowledges each TL-SDU 
before the sending LLC entity may continue with the next TL-SDU). 

During a segment transmission the sending LLC entity may force a sending of an acknowledgement 
whenever it sends the last segment of a TL-SDU, which is sent as the AL-FINAL-AR PDU, refer to 
subclause 22.2.2.3. The sending LLC entity may also request an acknowledgement at any time using an 
AL-DATA-AR PDU type, which also initiates an acknowledgement as soon as possible, see figures 129 
and 130. 

This window mechanism shall not be used for flow control purposes, refer to subclause 22.2.2.7. 
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Figure 129: PDU exchange for forced acknowledgement 
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Figure 130: Forced acknowledgement 
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22.2.2.6 Selective re-transmission of segments (AL-ACK) 

The selective re-transmission is based on the segments (LLC PDUs) into which the transmitting LLC 
divides a TL-SDU for sending. The receiving LLC informs the transmitting LLC which segments are not 
received correctly, and then the transmitting LLC sends the missing segments in the later transmissions 
until the whole TL-SDU is received correctly as recognised by the MAC layer error detection. The whole 
TL-SDU may still be erroneous and the receiving entity shall ask a re-transmission, when an error in the 
TL-SDU is detected by the frame check sequence. 

Figure 131 shows an example of a selective re-transmission sequence. Line a) of the figure shows three 
TL-SDUs, which the LLC divides into segments as shown in the line b). The end of each SDU is marked 
by "F" and the LLC sends that segment using a AL- FINAL PDU. The SDU window size is 2 in this 
example. 

The transmitting LLC plans to send segments as shown on line b) of the figure and starts to send them in 
sequence using AL-DATA PDUs for all but the last one which it sends using AL-DATA-AR PDU marked 
by "A". The receiving LLC receives correctly segments 1, 2, 4, 5 from the first SDU as shown on line c), 
and sends the first acknowledgement (ACK) as requested by the sending entity. The acknowledgement 
contains bit maps as shown on line e) and corresponding segment numbers are shown on line 0- The first 
part of the ACK (1/3) indicates the first segment, which is not received correctly, in this example segment 
number 3 in the first SDU and a bit map from that segment onwards. The acknowledgement tells that all 
segments before the 3rd segment of the first SDU (1/3) are received correctly and that segment 3 of the 
first SDU is not yet received correctly. Then the bitmap shows that segments 4 and 5 are received 
correctly. 

The transmitting LLC then modifies its transmission and adds those segments, which were not 
acknowledged or sent i.e. 3 and 6 from the first SDU (1/3 and 1/6), before continuing transmission of new 
segments in this case from the second SDU. The last segment of the second SDU is sent as 
AL-FINAL-AR PDU marked "F/A". The second and third acknowledgements on line d) indicate that again 
segments 3 and 6 from the first SDU are not yet received correctly, but the second SDU is received totally 
and correctly (2/A). The transmitting LLC then re-sends segments 3 and 6 of the first SDU and cannot 
continue to the third SDU due to SDU window size of two in this example. 

The receiving LLC misses again the segment number 3 of the first SDU as shown on line g) and the 
receiving LLC sends acknowledgement after receiving the 6th and final segment of the first SDU. The first 
acknowledgement indicates that only the third segment of the first SDU is not yet received correctly. The 
transmitting LLC then re-sends the missing segment of the first SDU and after receiving the second 
acknowledgement on the line h) can send the third SDU, which fits into the new SDU window. That SDU is 
received correctly as indicated by each segment CRC, but the total frame check sequence does not 
match and the receiving LLC sends an acknowledgement indicating a re-sending request (3/F) of the third 
SDU. After re-sending on line j) the third SDU is this time received correctly and acknowledged on line k) 
(3/A). 

In this example the receiving LLC will deliver the first TL-SDU to the MLE only after receiving the second 
acknowledgement on the line i) f which indicates that the first SDU is correctly received. The second SDU 
is already correctly received and acknowledged by the second acknowledgement on the line d), but the 
receiving LLC can not deliver it before the first SDU is received to keep SDUs in the correct sequence. 
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Figure 131: Selective re-transmission example 



If the AL-FINAL-AR is lost and there is no more data to send or the transmission window is closed and the 
last acknowledgement is also lost, then the sending entity may repeat the whole last sending or only the 
segments which were sent with the acknowledgement request. 



22.2.2.7 



Flow control 



The receiving advanced link entity may at any time request its peer entity to stop transmission of data 
PDUs by sending an AL-RNR PDU. The AL-RNR PDU replaces the AL-ACK PDU, when the receiver is 
not ready to receive new PDUs. The re-transmission of the segments or PDUs indicated in AL-RNR PDU 
shall continue. The data transmission may continue after the receiving entity has sent a AL-ACK PDU, 
refer to figures 132 and 133. The receiver not ready indication is valid from the last received AL-RNR PDU 
for the duration of T.271 seconds after which the transmitter may try to re-start data sending. 
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Figure 132: Flow control PDU exchange 
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Figure 133: Flow control 



22.2.2.8 



Connection reset 



The connection reset may be performed using connection set-up procedure, refer to subclause 22.2.2.1. 



22.2.2.9 



Releasing the acknowledged advanced link (AL-DISC PDU) 



The advanced link may be closed at any time by using the TL-DISCONNECT request primitive. Any 
on-going data transfer shall be stopped immediately with the possible result of data loss, refer to 
figures 134 and 135. When the LLC starts a disconnection, see figure 135, then the timer T.263 shall be 
started at the TL-DISCONNECT request. On a reception of AL-DISC or when timer T.263 has expired 
N.263 times without success, a TL-DISCONNECT confirm is given to the service user. The LLC shall 
discontinue to use the advanced link immediately at the reception of an AL-DISC PDU. 
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Figure 134: PDU exchange for releasing the advanced link 
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Figure 135: Disconnection of an advanced link 
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22.2.2.10 Releasing the unacknowledged advanced link (AL-DISC PDU) 

The unacknowledged advanced link is suppressed by using the disconnect primitive, refer to figures 136 
and 137. The AL-DISC PDU may be repeated to increase reception probability. Disconnection may occur 
at any time and after that instance that unacknowledged link does not support unacknowledged data 
transfer. 
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Figure 136: PDU exchange for releasing the unacknowledged advanced link 
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NOTE: AL-DISC may be repeated. 



Figure 137: Disconnection of an unacknowledged advanced link 
22.3 LLC procedures 

In this subclause the word "shall" is used with service primitives for traceability reasons in the protocol 
model, but the primitives are not testable and do not imply any implementation. 

22.3.1 Common procedures for all services 

This subclause describes protocol procedures, which are used in all LLC services or which are common 
to all services. 

22.3.1.1 End-point identifiers 

End-point identifiers between the service user (MLE) and LLC shall serve to distinguish between the 
multiple concurrent services, e.g. among several advanced links and their associated basic links. These 
identifiers may be local. The endpoint identifiers between LLC and MAC maintain this distinction, i.e. the 
LLC shall associate the service to a particular link while the MAC shall associate the link to a particular 
timeslot number or numbers for multislot service (offering more throughput). Acknowledgement shall use 
the same end-point identifier in the LLC. 

In addition to the end-point identifier the LLC shall associate a handle to each TL-SDU for further 
referencing. In a similar way the MAC associates a handle to each data request and the LLC shall use that 
handle when it refers to that transmission. The handles shall cease to exist, when the requested service is 
completed successfully or unsuccessfully. 



AL-DISC(close) 



AL-DISC(close) 



TL-DISCONNECT request 



Page 412 

ETS 300 392-2: March 1996 

22.3.1.2 Addressing 

At the transmitting LLC entity, the LLC shall get the address in use as a parameter from the service user 
in the primitive types request and response and shall give it to the MAC as a parameter. At the receiving 
entity, it shall get the address in use from MAC and shall give it to the service user in the primitive types 
indication and confirm as a parameter. The LLC shall copy the same address parameters as in the 
corresponding TMA-UNITDATA indication primitive to the acknowledging TMA-UNITDATA request 
primitive unless an address is available with the corresponding LLC sen/ice user response primitive. 

NOTE: ITSIs and GTSIs in a MS are independent of each other and LLC services recognise 
addresses to allow concurrent basic or advanced link services. This ETS does not 
describe how addresses affect to the LLC implementation. 

22.3.1 .3 User data buffering 

The sending LLC entity shall buffer TL-SDUs in order to offer re-transmission until individually marked as 
correctly received, or the maximum number of re-transmissions is exceeded or TL-SDU is cancelled by 
the service user or, in addition in the case of an advanced link, the link is either disconnected or re-set. 
When transmitting segmented TL-SDUs, the segmentation and the segments shall be preserved for 
further re-transmissions until the TL-SDU is completely acknowledged or maximum number of 
re-transmissions is exceeded. 

The LLC sub-entities shall update their part of the DATA-IN-BUFFER signal so often, that the MAC layer 
can update resource requests in time to prevent unnecessary breaks and random accesses in uplink data 
transfer, see subclause 22.3.1 .7. 

The amount of data that may be buffered for transmission inside LLC layer is implementation dependent. 
This model deletes all not yet transmitted data in the advanced link buffers, when the advanced link is 
reset by a new set-up. 

22.3.1 .4 Cancelling SDU transmission 

This procedure is local to the MS, but affects the data transfer over the air interface. 

On the basic link the service user may cancel an ongoing transmission of a TL-SDU. On the reception of 
a TL-CANCEL request from the service user the LLC shall delete the TL-SDU indicated by the handle in 
the TL-CANCEL request, if that TL-SDU is still in the transmission buffer and no part of it is transferred to 
the MAC layer, and shall indicate the cancellation to the service user in a TL-REPORT indication (aborted, 
TL-SDU not completely sent). Otherwise LLC shall forward cancellation request to the MAC as 
aTMA-CANCEL request. If the corresponding MAC TMA-REPORT indication (aborted, TM-SDU not 
completely sent) shows that the MAC has aborted the transmission and the TM-SDU has not been 
completely sent, then the LLC shall delete the corresponding TL-SDU from the sending buffer and shall 
indicate the cancellation to the service user in a TL-REPORT indication (aborted, TL-SDU not completely 
sent). If the MAC has sent the whole SDU containing the TL-SDU for which a cancellation was requested, 
then the MAC will indicate with a TMA-REPORT indication (aborted, TM-SDU sent at least once), that the 
whole TL-SDU is sent. The LLC shall then delete the corresponding TL-SDU from the sending buffer and 
indicate in a TL-REPORT indication (aborted, TL-SDU sent at least once) to the service user, that the DLL 
has aborted sending actions, but the TL-SDU has been sent at least once. 

NOTE 1: If the LLC has transferred the SDU to the MAC more than once, then it is the LLC's 
responsibility to issue the correct TL-REPORT indication to the higher layers, taking 
into account also the results of the previous transmission attempts. 

In the advanced link the DLL can cancel the transmission of the TL-SDU only if the first segment has not 
been sent at all. On the reception of a TL-CANCEL request from the service user the LLC shall delete 
from the transmission buffer a TL-SDU, if sending has not started and indicate in a TL-REPORT, that 
cancellation is completed and the TL-SDU is not sent. If the LLC has delivered only the first segment of 
the TL-SDU to the MAC and that segment is not yet acknowledged, then the LLC shall forward 
cancellation request to the MAC as a TMA-CANCEL request. If the corresponding MAC TMA-REPORT 
indication shows that the MAC has aborted the transmission and the TMA-SDU corresponding to the first 
segment has not been sent at all, then the LLC shall delete the corresponding TL-SDU from the sending 
buffer and shall indicate the successful cancellation (the TL-SDU is not completely sent) to the service 
user in a TL-REPORT indication. 
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If the TMA-REPORT indication shows that the MAC has sent the TMA-SDU corresponding to the first 
segment at least once, then the LLC shall indicate with a TL-REPORT indication (layer two transmission 
activities continuing) and continue TL-SDU transmission. 

The advanced link service user may also stop transmission of a TL-SDU by disconnecting or resetting by 
a new set-up the corresponding advanced link, refer to subclause 22.3.3.3 and subclause 22.3.3.1. 

NOTE 2: The DLL always responds to a TL-CANCEL request with a TL-REPORT indication. 

22.3.1 .5 Extended error protection 

An extended error detection (FCS) shall be offered as a selectable part of the service on basic link and as 
a mandatory part of the service on the advanced link. When appropriate the sending LLC shall calculate 
over the TL-SDU a FCS and shall append it to the TL-SDU. 

When a FCS is appended to the TL-SDU, then the receiving LLC entity shall test the received TL-SDU 
against the FCS to detect whether errors have been introduced into the TL-SDU during transmission. 
When the receiving LLC detects errors in the received TL-SDU, the LLC shall not pass the erroneous 
TL-SDU to the service user, but instead the LLC shall discard the erroneous TL-SDU and enforce an SDU 
re-transmission if appropriate. 

The FCS is defined in annex C. 

22.3.1 .6 Timers and counters 

In the protocol description, timers and counters are referred either by their names or by their value 
symbols or both e.g. set-up waiting timer T.261 . Stopping of timers and counter re-settings are shown only 
when implicit reasons are not obvious. This protocol does not define or restrict any implementation of 
timers or counters. 

22.3.1 .7 Formatter protocol 

The sending formatter controls the transmission order of the LLC PDUs. It delivers LLC PDUs to the MAC 
according to the relative priority order of the PDUs using TMA-UNITDATA request primitives. The 
receiving formatter identifies LLC PDU headers in the MAC TMA-UNITDATA indication primitives and 
delivers the PDUs to the corresponding LLC entities. 

22.3.1 .7.1 MS formatter receiving entity 

Upon reception of a TMA-UNITDATA indication primitive the formatter shall decode the PDU type. The 
formatter shall route the corresponding PDU according to the PDU type, endpoint identifier and address to 
the appropriate LLC protocol sub-entity instance. If the formatter recognises a PDU ( which is not valid for 
the current composition of LLC entities, then the formatter shall discard the PDU without any further 
actions. 

22.3.1 .7.2 MS formatter sending entity 

The LLC shall indicate to the MAC the availability of data to be transmitted with the DATAJNJ3UFFER 
signal, which specify the total amount of all outstanding data of ail LLC sub-entities (including pending 
acknowledgements) and the highest priority and stealing permission for that data. In the case of an 
emergency message the formatter should deliver the corresponding DATA_IN_BUFFER signal to the 
MAC before a possible TMA-CANCEL request so that MAC could make a new resource request during 
the cancel process. 

Upon reception of MAC-READY from MAC, the LLC shall decide which of the outstanding PDUs have to 
be sent, depending on the protocol needs and the size of the next MAC block. Within the same service, 
acknowledgements shall be sent prior to any data PDUs. Basic link PDUs shall be sent before advanced 
link PDUs unless the priority of the advanced link PDUs is higher than the priority of the basic link PDUs. 
The LLC shall deliver the PDU to the MAC using a TMA-UNITDATA request primitive. The MAC should 
immediately return a handle in a TMA-REPORT indication for further referencing in a TMA-CANCEL 
request and in other TMA-REPORT indications. 
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There may be multiple MAC-READY and TMA-UNITDATA request exchanges, if MAC is performing an 
association of LLC PDUs into one MAC block. 

The MAC will select the relevant means to transfer the information, i.e. either by random or reserved 
access or frame stealing, as appropriate based on the selected priority and stealing permission 
parameter. 

22.3.2 Basic fink procedures 

The basic link shall offer two services, acknowledged and unacknowledged data transfer. The 
acknowledged service supports also a data response service primitive for call set-up optimisation. The 
data with the response primitive is transmitted using an acknowledge message without an explicit 
acknowledgement, see subclause 22.2.1 .1 . 

The basic link LLC protocol of the MS is modelled by two processes, BL_LLC_MS and Formatter, the 
latter being common with the advanced links, refer to figure 102. 

This ETS models the numbering of TL-SDUs and acknowledgements and local function indicators by local 
variables. Each basic link shall employ separate sets of variables, parameters and timers. At the sending 
side variables and main parameters are: 

N(S) TL-SDU number in the sent data PDUs; 

N(R) TL-SDU number in the received acknowledgement PDUs; 

V(S) the next TL-SDU number to be sent or to be re-sent; 

and at the receiving side: 

N(S) TL-SDU number in the received data PDUs; 
N(R) TL-SDU number in the sent acknowledgement PDUs; 
V(R) the last received TL-SDU number. 
Timers and constants are defined in annex A. 

NOTE: This protocol description is valid for one basic link, which uses one address. 

22.3.2.1 Establishment of information transfer in basic link 

No explicit establishment is required for the basic link. At least one basic link shall be available, when the 
MS is synchronised to a BS. When there is no advanced link nor circuit mode connection, then there is a 
single basic link on the corresponding control channel. When there are any defined advanced links or 
circuit mode connections, then there is one basic link per each advanced link and circuit mode 
connection. If an advanced link uses same physical resource allocations as a circuit mode connection, 
then there is only one basic link associated with the pair. 

The MS shall keep all basic links that are not removed in the physical resource allocation, if the MS is 
capable of operation on concurrent channels, see clause 23. The BS may allocate e.g. the first advanced 
link and the basic link associated to a circuit mode call so that the previous basic link on the initiating 
control channel is released. 

After power on or in the first transmission, when roaming or migrating to a new BS the MS LLC shall start 
TL-SDU numbering from "0 n by setting local variable V(S)=0. 

22.3.2.2 Quality of service selection 

The service user shall define the quality of service for each message by selecting a basic link and the 
primitive type either TL-DATA request or TL-UNITDATA request and by selecting the parameters in that 
primitive, see definition of parameters in clause 20. The undetected message error rate shall be defined 
by selecting the use of the FCS. The TL-PDU sending order in the selected basic link and in relation to the 
concurrent advanced link shall be defined by the requested priority, which may change the transmission 



Page 415 

ETS 300 392-2: March 1996 

order of TL-SDUs. The priority shall affect the transmission of a already started TL-SDU sending only if 
the highest priority (emergency) is used and the sending of the current TL-SDU is destroyed by 
cancellation. 

NOTE: The maximum data transfer throughput of an associated basic link is defined by the 
associated advanced link or circuit mode call. 

22.3.2.3 Acknowledged data transmission in basic link 

The acknowledged data transmission is modelled by the states in the sending process: 

TX_READY transmitter is ready to send next TL-SDU; 
and in the receiving process: 

RX_READY receiver is ready to receive data from the MAC. 

Each acknowledged information transfer is identified by a TL-SDU number N(S) both in BL-DATA and 
BL-ADATA PDUs. The acknowledgement contains the number N(R) of the correctly received TL-SDU 
both in BL-ACK and BL-ADATA PDUs. In addition, the receiver has the possibility to send data in a 
TL-DATA response primitive together with the acknowledgement without a sequence number. The N(R) in 
that acknowledgement marks the TL-SDU sent using an acknowledgement BL-ACK PDU. 

The LLC process may receive: 

service user service primitive: 

a) a TL-DATA request primitive and then the LLC shall: 

i) issue an immediate TL-REPORT indication containing a handle to the TL-DATA 
request; 

ii) calculate FCS, when requested, and append it to TL-SDU; 

iii) place the TL-SDU into transmission buffer according to the indicated priority; 

iv) indicate new data in the transmitting buffer to the formatter using DATAJN_BUFFER 
signal; 

v) in the case of a TL-DATA request with the emergency priority and if there is an 
ongoing lower priority TL-DATA (or TL-UNITDATA) PDU in transmission on that basic 
link at the MAC layer, then the LLC may deliver a TMA-CANCEL primitive via formatter 
to the MAC, see subclause 22.3.1.4. The LLC shall not cancel a BL-ACK PDU with or 
without service user data. The LLC may cancel a BL-ADATA PDU and memorise the 
N(R) in it; 

b) a TL-DATA response primitive to the TL-DATA indication primitive before the corresponding 
acknowledgement is sent and then the LLC shall: 

i) calculate FCS, when requested, and append it to TL-SDU; 

ii) format a BL-ACK PDU (N(R) = V(R)) with the (optional) TL-SDU from the TL-DATA 
response primitive; 

iii) inform the formatter using D AT A_l N_BU FFE R signal; 
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c) a TL-DATA response primitive after sending the corresponding BL-ACK or BL-ADATA PDU, 
then the LLC shall: 

i) issue an immediate TL-REPORT indication containing a handle to the TL-DATA 
response as if it were a TL-DATA request primitive; 

ii) calculate FCS, when requested, and append it to TL-SDU; 

iii) place the TL-SDU into transmission buffer according to the indicated priority; 

iv) indicate new data in the transmitting buffer to the formatter using DATAJN_BUFFER 
signal; 

v) in the case of a TL-DATA response with emergency priority and if there is an ongoing 
lower priority TL-DATA (or TL-UNITDATA) PDU in transmission on that basic link at 
the MAC layer, then the LLC may deliver a TMA-CANCEL primitive via formatter to the 
MAC, see subclause 22.3.1 .4. The LLC shall not cancel a BL-ACK PDU (which in this 
situation should be without user data). 

local indications: 

d) a MAC-READY indication from the formatter and then: 

if a BL-ACK PDU is ready due to a TL-DATA response, then the LLC shall issue it to 
the formatter with an acknowledgement number N(R) = V(R); 

if there is a waiting acknowledgement and a TL-DATA request available, then the LLC 
shall: 

i) set N(S) = V(S) for the TL-SDU to be sent; 

ii) set N(R) = V(R) for the waiting acknowledgement; 

iii) form the corresponding BL-ADATA PDU and issue it to the formatter; 

if there is a waiting acknowledgement and neither a TL-DATA response nor a 
TL-DATA request available, then the LLC shall issue a BL-ACK PDU with an 
acknowledgement number N(R) = V(R) to the formatter without any service user data; 

if there is no waiting acknowledgement but a TL-SDU is available, then the LLC shall 
set N(S) = V(S) for the TL-SDU to be sent, form the corresponding BL-DATA PDU and 
issue it to the formatter; 

e) a TMA-REPORT indication (handle) and if it is due to a BL-DATA or BL-ADATA PDU, then 
the LLC shall memorise it; 

f) a TMA-REPORT indication (one of the complete TM-SDU transmission indications) and if it 
is due to a PDU which contained service user data in either a BL-DATA or BL-ADATA PDU 
and the PDU transmission was successful and complete transmission by random access or 
complete transmission by reserved access or stealing, then the LLC shall start the re-try 
timer T.251 ; and in any case, if this is the first transmission of the TL-SDU, then the LLC shall 
issue a TL-REPORT indication (first complete transmission) to the service user; 

g) a TMA-REPORT indication (random access failure) and if it is due to a PDU which contained 
service user data, then the LLC shall inform the service user of unsuccessful transmission by 
TL-REPORT primitive (failed transfer), and delete the corresponding TL-SDU from the 
sending buffer. If the report was due to a BL-DATA or BL-ADATA PDU, the LLC shall 
increment V(S); 

h) a TMA-REPORT indication (fragmentation failure) and 

if it is due to a BL-ACK PDU, then the LLC shall discard the optional TL-SDU; 
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if the report is due to a BL-DATA or BL-ADATA PDU and the number of allowed re- 
transmissions N.252 of the corresponding TL-SDU is not exceeded, then the LLC shall 
keep the TL-SDU for re-transmission and inform the formatter by a 
DATA_IN_BUFFER signal; or 

otherwise the LLC shall inform the service user of unsuccessful transmission by 
TL-REPORT primitive (failed transfer), increment V(S) and delete TL-SDU from the 
sending buffer; 

i) re-try timer T.251 expires and 

if the number of allowed re-transmissions N.252 is not exceeded, then the LLC shall 
keep the TL-SDU in the sending buffer for re-transmission and inform the formatter by 
a DATAJN.BUFFER signal; or 

otherwise the LLC shall inform the service user of unsuccessful transmission by 
TL-REPORT primitive (failed transfer), increment V(S) and delete TL-SDU from the 
sending buffer; 

PDU from the peer entity: 

j) a BL-ACK and then: 

if there is a TL-SDU waiting for a re-transmission in the sending buffer, then: 

if the TL-SDU number (in the BL-ACK PDU) N(R) = V(S), then the LLC shall confirm 
the success of the transmission to the service user by a TL-DATA confirm (successful 
transfer) primitive and deliver the contained TL-SDU, if any, increment V(S), delete the 
TL-SDU waiting for a re-sending from the sending buffer and stop the re-try timer 
T.251; or 

if the TL-SDU number (in the BL-ACK PDU) N(R) is not equal to V(S), then the LLC 
shall deliver contained TL-SDU, if any, using TL-DATA indication; and 

if the number of allowed re-transmissions N.252 of the TL-SDU is not exceeded, then 
the LLC shall keep the corresponding TL-SDU in the sending buffer for re-transmission 
and inform the formatter by the D AT AJ N_B U FFE R signal; or 

if the number of allowed re-transmissions N.252 of the TL-SDU is exceeded, then the 
LLC shall inform the service user of unsuccessful transmission by a TL-REPORT 
primitive (failed transfer), increment V(S), stop re-try timer T.251 and discard the 
corresponding TL-SDU from the sending buffer; 

if there is no TL-SDU waiting for a re-transmission in the sending buffer, then the LLC 
shall deliver contained TL-SDU, if any, using TL-DATA indication; 

k) a BL-DATA PDU and then: 

i) the LLC shall delete the possible BL-ACK PDU from the sending buffer; 

ii) the LLC shall: 

if the FCS is used and it is correct or FCS is not used, then the LLC shall deliver 
TL-SDU to the service user in a TL-DATA indication service primitive, memorise 
a waiting acknowledgement with number V(R) = N(S), start to wait for TL-DATA 
response and inform the formatter by the D ATAJ N_B U FFE R signal; 

if the FCS is used and it is not correct, then the LLC shall memorise a waiting 
acknowledgement with number V(R) = N(S)-1 and inform the formatter by the 
D ATAJ N_BU FFE R signal; 
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I) a BL-ADATA PDU and then the LLC shall separate the acknowledgement N(R) and incoming 
TL-SDU including N(S) and shall continue as if LLC had received a BL-ACK PDU (without 
service user data) first and then a BL-DATA PDU. 

The LLC shall set the stealing permission parameter to "steal within time T.214 H for the BL-ACK PDU in 
the basic link protocol in case the MAC currently has traffic transmit permission. The LLC should also set 
priority level = 5 (though this parameter will not normally be used by the MAC). 

NOTE 1 : At the reception of a new BL-DATA PDU before acknowledging the previous received 
BL-DATA PDU the LLC stops all acknowledgement actions of the previous TL-SDU 
independently of the TL-SDU number N(S). 

NOTE 2: The defined protocol and PDU numbering supports the receiving peer entity to request 
a TL-SDU re-sending, but it does not guarantee alone a safe mechanism for 
suppression of duplicate TL-SDUs. 

NOTE 3: The transmission of a TL-SDU from a TL-DATA request primitive is totally independent 
of any data transmission in the other direction. On the other hand a TL-SDU from a 
TL-DATA response primitive is normally transferred in the corresponding 
acknowledgement of the TL-DATA indication primitive, if the TL-DATA response 
primitive is delayed too much, then the TL-SDU will be sent in a BL-DATA PDU and it 
will be acknowledged by a TL-DATA confirm primitive. 

NOTE 4: The random access failure prevents further TL-SDU sending re-tries and to increase 
the probability to get an emergency message through the MAC will use more random 
access re-tries for higher priority TL-SDUs. 

22.3.2.4 Unacknowledged data transfer in the basic link 

The procedures in a MS for unacknowledged data transfer in the basic link are described in the following 
subclauses. 

22.3.2.4.1 Actions on TL-UNITDATA request (sending entity) 

During sending of unacknowledged service user data the LLC may receive: 

a) a TL-UNITDATA request from the service user and then: 

the LLC shall issue an immediate TL-REPORT indication containing a handle to the 
TL-UNITDATA request; 

if requested by the service user, then the LLC shall calculate and append a FCS to the SDU; 

the LLC shall store TL-SDU in priority order into the sending buffer for sending N.253+1 
times, and inform formatter with the DATAJN_BUFFER signal; 

b) a MAC-READY from the formatter and then the LLC shall deliver the highest priority 
(unacknowledged service) TL-SDU as a BL-UDATA PDU to the formatter; 

c) a TMA-REPORT indication giving a handle to the TMA-UNITDATA request; 

d) a TMA-REPORT indication (successful complete transmission by random access), and then the 
LLC shall remove the TL-SDU from the transmitting buffer and deliver a TL-REPORT indication 
primitive (transfer completed) to the service user; 

e) a TMA-REPORT indication (complete transmission by stealing or by reserved access), and if that 
TL-SDU has now been completely transmitted N.253+1 times, then the LLC shall remove the 
TL-SDU from the transmitting buffer and deliver a TL-REPORT indication primitive (transfer 
completed) to the service user; 
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f) a TMA-REPORT indication (failure of fragmentation process) and then the LLC shall try to re-send 
the TL-SDU so that there shall be at maximum N. 253+1 failed transmissions in addition to the 
N.253+1 complete transmissions. If there has not been N.253+1 complete transmissions when the 
maximum number of failed transmissions N.253 +1 has been reached, then the LLC shall remove 
the TL-SDU from the sending buffer and issue a TL-REPORT indication primitive (failed transfer) to 
the service user; 

g) a TMA-REPORT indication (random access failure) and then the LLC shall remove TL-SDU from 
the sending buffer and issue a TL-REPORT indication (failed transfer) to the service user. 

22.3.2.4.2 Actions on BL-UDATA PDU (receiving entity) 

Upon reception of a BL-UDATA PDU from the formatter: 

i) if indicated by the received PDU, LLC shall calculate FCS and: 

if the FCS is correct, the LLC shall inform the service user of a reception of a TL-SDU using 
a TL-UNITDATA indication; 

If the FCS is not correct, the LLC shall discard the SDU; 

ii) if the received PDU does not contain FCS, then the LLC shall issue the TL-SDU to the service user 
using a TL-UNITDATA indication. 

NOTE: The basic link protocol does not suppress received duplicates. 
22.3.3 Advanced link procedures for the acknowledged service 

The LLC advanced link protocol of the MS is modelled by processes: AL_MAIN, AL_TX, AL_RX and 
Formatter, the latter being common also with the basic link and unacknowledged advanced link services, 
refer to figure 102. Refer to subclause 22.3.1 .7. for formatter processes. 

This standard models the numbering of TL-SDUs and acknowledgements and local function indicators by 
local variables. Each advanced link shall employ separate sets of variables, parameters and timers. 

At the sending entity: 

N(S) TL-SDU number in the sent data PDUs; 

N(R) TL-SDU number in the received acknowledgement PDUs; 

S(S) Segment number in the sent data PDU; 

S(R) Segment number in the received acknowledgement PDU. 

At the receiving entity: 

N(S) TL-SDU number in the received data messages; 

N(R) TL-SDU number in the sent acknowledgement messages; 

S(S) Segment number in the received data PDU; 

S(R) Segment number in the sent acknowledgement PDU; 

Timers and constants are defined in annex A. 

In figure 102 the AL-MAIN controls independently the state of each advanced link. 
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Each advanced link set-up, data transfer and disconnection phase is modelled by states: 

IDLE link is not ready for data transfer; 

WAITJN_CONNECT link is in the incoming set-up phase; 

WAIT_OUT_CONNECT link is in the outgoing set-up phase; 

WAIT_DISCONNECT link is waiting for outgoing disconnection; 

CONNECTED link is ready for data transfer. 

The acknowledged information transfer in the CONNECTED state of each advanced link (N.261) is 
modelled by a single state in the sending process: 

AL_TX_READY transmitter is ready to send the next TL-SDU; 

and respectively by a single state in the receiving process: 

AL_RX_READY receiver is ready to receive data from the MAC. 

NOTE: It is recommended that the MS does not use fragmentation for sending advanced link 
PDUs. 

22.3.3.1 Advanced link establishment for the acknowledged service 

The service user shall set-up the advanced link before any data transmission may occur. The advanced 
link is available for data transfer until the service user or the LLC entity disconnects it. The advanced link 
number may be used locally as a part of the endpoint identifier related to an advanced link and its timeslot 
or timeslots used to send and receive the LLC PDUs. The established advanced link can be used for two- 
way information transfer. 

There can be only one connection set-up in progress at the same time. If there are colliding set-ups from 
both peer entities, then those will be merged into a single set-up process. 

The service user shall define the quality of service by setting up an advanced link and later by selecting 
that advanced link for the data transmission. The quality of service parameters applicable to the LLC layer 
are defined in clause 20. 

22.3.3.1 .1 Actions on TL-CONNECT request (set-up phase sending entity) 

Upon reception of a TL-CONNECT request in any state, the LLC: 

i) if the corresponding advanced link is already set-up, then the LLC shall cease both sending and 
reception actions, if needed cancel the relevant MAC layer SDU by a TMA-CANCEL request 
primitive, empty relevant data buffers and prepare an AL-SETUP PDU with a report "reset"; or 

if the corresponding advanced link is not already set-up, then the LLC shall prepare an AL-SETUP 
PDU with a report "service definition"; 

ii) set re-try counter to allow the maximum number of connection set-up retries N.262; 

iii) inform formatter using D ATAJ N_BU FFE R signal and enter "WAIT_OUT_CONNECT" state. 

NOTE: The LLC selects parameters for an AL-SETUP PDU according to the TL-CONNECT 
request parameters and current LLC capabilities e.g. available buffer sizes, see 
clause 20 for parameter definitions and clause 21 for PDU definitions. Suitable 
parameters for a AL-SETUP PDU depend on the quality negotiation between the 
service user and the DLL. The negotiation method is implementation dependent. 
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In the "WAIT_OUT_CONNECT" state the LLC may receive: 
Local indication: 

a) a MAC-READY signal and then the LLC shall deliver the waiting AL-SETUP PDU, if any, to the 
formatter; 

b) a TMA-REPORT indication (handle), which the LLC shall memorise; 

c) a TMA-REPORT indication (complete transmission) and if reason is "successful complete 
transmission by random access" or "complete transmission by reserved access or stealing", then 
the LLC shall start set-up waiting timer T.261 ; 

d) a TMA-REPORT indication (random access failure) and then the LLC shall inform a set-up failure to 
the service user by TL-REPORT indication primitive (set-up failure) and return into the "IDLE" state; 

e) set-up waiting time-out T.261 indication and: 

if more retries (N.262) are available, then the LLC shall issue the previous AL-SETUP PDU 
into the transmission buffer and inform formatter by the DATAJNJ3UFFER signal; 

if all retries (N.262) are used, then the LLC shall inform a set-up failure to the service user by 
TL-REPORT indication primitive (set-up failure) and return into the "IDLE" state; 

PDUs from peer entity: 

f) an AL-SETUP PDU with the report "success" and then the LLC shall issue a TL-CONNECT confirm 
to the service user, stop set-up waiting timer T.261 , prepare advanced link for data transfer in state 
"CONNECTED"; 

g) an AL-SETUP PDU with report "service change" and: 

if the parameters are acceptable, then the LLC shall prepare an AL-SETUP PDU with report 
"success" and inform formatter using DATAJN_BUFFER signal. The LLC shall continue in 
the "WAIT_IN_CONNECT" state as defined in subclause 22.3.3.1.2 e) to h); 

if the parameters are not acceptable, but there is a possibly suitable parameter set available, 
then the LLC shall prepare an AL-SETUP PDU with report "service change" and inform 
formatter using DATAJN_BUFFER signal; 

if the parameters are not acceptable and there is no suitable parameter set available, then 
the LLC shall prepare an AL-DISC PDU with report "service not supported" and inform 
formatter using DATAJN_BUFFER signal and deliver the AL-DISC PDU to the formatter as 
the response to the MAC-READY signal and then inform the service user by a TL-REPORT 
indication "set-up failure" and return to the "IDLE" state; 

h) an AL-SETUP PDU with report "service definition" and then the LLC shall continue as described in 
subclause 22.3.3.1.2 for the "IDLE" state; 

i) an AL-DISC PDU with report "service not supported", "service temporarily not available" or "reject" 
and then the LLC shall inform the service user by the corresponding TL-REPORT indication and 
return to the "IDLE" state. 

22.3.3.1 .2 Actions on AL-SETUP PDU reception (set-up phase receiving entity) 

If the LLC is capable of supporting advanced link, then upon reception of an AL-SETUP PDU with one of 
the reports "service definition", "service change" or "reset" in the "IDLE" state, the LLC shall inform the 
service user by a TL-CONNECT indication with corresponding report and start to wait in state 
"WAITJN_CONNECT". 

If the LLC does not for the moment support advanced link, then upon reception of an AL-SETUP PDU the 
LLC shall prepare an AL-DISC PDU with a report "service temporarily not available", inform formatter by 
DATAJN_BUFFER signal and issue the AL-DISC PDU as a response to the next MAC-READY signal. 
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If the LLC does not at all support advanced link, then upon reception of an AL-SETUP PDU the LLC may 
prepare an AL-DISC PDU with a report "service not supported", inform formatter by D AT AJ N_B U FFE R 
signal and issue the AL-DISC PDU as a response to the next MAC-READY signal. 



While waiting in state "WAIT_IN_CONNECT" the LLC may receive: 



service user initiated service primitives: 



a) a TL-CONNECT response primitive with the same parameters as in the TL-CONNECT indication 
and then the LLC shall prepare an AL-SETUP PDU with same parameters as in the received AL- 
SETUP PDU with a report "success" and inform the formatter by a DATA_IN_BUFFER signal; 

b) a TL-CONNECT response primitive with different parameters (less QoS) as in the TL-CONNECT 
indication and then the LLC shall prepare an AL-SETUP PDU with suitable parameters (QoS) and 
with a report "service change", inform the formatter by DATAJN_BUFFER signal and continue in 
the "WAIT_OUT_CONNECT" state as defined in subclause 22.3.3.1.1. 

c) a TL-CONNECT request primitive and then the LLC shall continue as if it had received that primitive 
from the service user as a sending entity, see subclause 22.3.3.1 .1 . 

d) a TL-DISCONNECT request primitive and then the LLC shall prepare an AL-DISC PDU with a 
report "reject", inform formatter by DATA_IN_BUFFER signal and issue the AL-DISC PDU to the 
formatter as a response to the next MAC-READY signal and then return to the "IDLE" state. 

Local indications due to the AL-SETUP PDU with the report "success" sending: 

e) a MAC-READY signal and then the LLC shall deliver the waiting AL-SETUP PDU to the formatter; 

f) a TMA-REPORT indication (handle), which the LLC shall memorise; 

g) a TMA-REPORT indication (successful complete transmission by random access or complete 
transmission by reserved access or stealing) and then the LLC shall prepare advanced link for data 
transfer in state "CONNECTED"; 

h) a TMA-REPORT indication (random access failure) and then the LLC may inform the service user 
by a TL-REPORT indication primitive (set-up failure) and the LLC shall return into the "IDLE" state. 

NOTE 1: The LLC entity should not normally receive an AL-SETUP PDU with a report "service 
change" or "reset" in the "IDLE" state, but if that happens, then the LLC should start 
normal connection establishment as if the received report were "service definition". 

NOTE 2: The LLC entity should not normally receive an AL-SETUP PDU with a report "success" 
in states "IDLE" and "WAIT_IN_CONNECT" ( but if that happens, then the LLC should 
start normal connection establishment sending an AL-SETUP PDU with a report 
"service definition" as defined in subclause 22.3.3.1 .1 . 



NOTE 3: A TL-CONNECT response from the service user with a different set of parameters 
than in the corresponding TL-CONNECT indication primitive is taken as a new connect 
request and the LLC will respond to it with a TL-CONNECT confirm primitive before 
the data transfer may start. 



22.3.3.1 .3 Actions on AL-SETUP PDU reception (data transfer state) 

Upon reception of an AL-SETUP PDU with a report "reset", "service definition" or "service change" in the 
"CONNECTED" state then: 



i) the LLC shall cease both sending and reception actions, empty relevant data buffers and, if needed, 
cancel any MAC layer sending by TMA-CANCEL request primitive; and 



ii) the LLC shall inform service user of the reset by a TL-CONNECT indication with the report "reset" 
and start to wait connection set-up progress in state "WAIT_IN_CONNECT" as defined in 
subclause 22.3.3.1.2. 
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22.3.3.2 Acknowledged data transfer 

In the advanced link, each data PDU in the acknowledged information transfer is identified by two 
numbers: a TL-SDU sequence number N(S) and a segment sequence number S(S). The TL-SDU 
sequence number is a three bit number incremented in a modulo manner with each transmitted TL-SDU. 
After the connection set-up or after a reset, the sending LLC entity shall start the TL-SDU numbering from 
"CT. The segment sequence number is an absolute eight bit number indicating segments inside a TL-SDU. 
Those numbers are used in the segmentation and re-assembly processes and in the selective 
re-transmission process. The acknowledgement contains the corresponding TL-SDU sequence number 
N(R) and in the selective acknowledgement PDU a segment sequence number S(R). The 
acknowledgement cannot carry any layer 3 information. 

The advanced link can be used for two-way information transfer. 

22.3.3.2.1 Segmentation and sequencing 

The sending advanced link LLC entity shall segment a TL-SDU, if the size of it exceeds available MAC 
SDU size. Segments shall be sent in sequence. In order to allow a re-assembly in the selective 
re-transmission, the segments are numbered using a S(S) starting from n 0 M for each TL-SDU. The 
segment numbering is absolute, therefore a TL-SDU shall not comprise more than 256 segments. 

The MAC sub-layer informs the next available segment size in the MAC-READY signal and the LLC 
should use the whole available size with possible exception of the last segment. The re-transmission of a 
segment shall not change the size of that segment, refer to subclause 22.3.3.2.3. 

The LLC shall use either AL-DATA or AL-DATA-AR PDU for a segment sending if the segment is not the 
last segment of a TL-SDU, and the LLC shall use either AL-FINAL or AL-FINAL-AR PDU if the segment is 
the last segment of a TL-SDU. The LLC shall use either AL-FINAL or AL-DATA PDUs if no 
acknowledgement is needed at this moment from the peer entity, and either AL-FINAL-AR or 
AL-DATA-AR PDU if acknowledgement is needed at this moment from the peer entity, refer to 
subclause 22.3.3.2.3. 

NOTE: The TL-SDU, as used in this definition, contains the FCS. 

22.3.3.2.2 Re-assembly 

Re-assembly is an operation opposite to segmentation. The receiving LLC entity shall re-assemble 
TL-SDU from the received segments. The advanced link protocol shall deliver received TL-SDUs to the 
service user in the TL-SDU sequence number order. 

22.3.3.2.3 Acknowledgement and segment re-transmission mechanisms 

In this LLC protocol the sending entity is responsible of requesting acknowledgements from the receiving 
entity. The sending LLC may request an acknowledgement from the peer LLC and potentially cease data 
transmission by using either AL-DATA-AR or AL-FINAL-AR PDU. The sending LLC shall request an 
acknowledgement at latest, when it cannot continue sending due to the closing of TL-SDU window. The 
sending LLC should request an acknowledgement each time there is no more data for sending or there 
will be a pause in sending for other reasons. The LLC should minimise acknowledgement requests in 
good propagation situations. 

In addition to the requested acknowledgements the receiver may choose to send acknowledgements at 
any time for its own purposes e.g. to clean up receiving buffers. 

The receiving entity acknowledges both whole TL-SDUs and selectively segments of TL-SDUs by either 
AL-ACK or AL-RNR PDUs depending on the flow control needs, refer to subclause 22.3.3.2.5. The 
sending entity shall re-transmit only the segments marked as bad in the last received AL-ACK or AL-RNR 
PDU. The re-transmission of segments shall start from the oldest segment in the oldest TL-SDU and 
continue until all segments for which a re-transmission is requested are transmitted. A segment shall keep 
its original sent segment number S(S), which indicates its absolute position inside the corresponding 
TL-SDU. The same sent TL-SDU number N(S) shall be used until all its segments have been successfully 
transmitted and the whole TL-SDU has been acknowledged (see subclause 22.3.3.2.6) or TL-SDU 
transmission is failed or the advanced link is disconnected. 
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Upon reception of the acknowledgement request indicated by the AL-DATA-AR or AL-FINAL-AR PDU, the 
receiver entity shall send either the AL-ACK or the AL-RNR PDU, refer to subclause 22.3.3.2.5. for flow 
control, with one or more acknowledgement blocks: 

i) the N(R) element shall indicate, which TL-SDU is acknowledged; 

ii) if the acknowledgement is for a whole TL-SDU, then the LLC shall set the acknowledgement length 
element to: 

value 000000 2 , if the receiver accepts the TL-SDU; 
value 1 1 1 1 1 1 2 , if the receiver requests a re-sending of the TL-SDU; 
and there shall be no other elements in that acknowledgement block; 

iii) if the receiver selectively acknowledges segments of the PDU then: 

the acknowledgement length element shall indicate the number of acknowledged segments; 
and 

the S(R) element shall indicate the absolute position of the oldest not yet received segment in 
the TL-SDU; and 

the bit map shall indicate the status of each segment starting from the next segment after the 
S(R) and moving forwards one segment at a time, up to the limit imposed by the last correctly 
received segment or by the available room in the AL-ACK or AL-RNR PDU; the status of the 
segment (STATUS) shall be set to "1" if it is correctly received and to "0" if it is not correctly 
received. 

The receiving entity shall include an acknowledgement block for the TL-SDU corresponding to the 
AL-DATA-AR or AL-FINAL-AR. It should also include an acknowledgement block for any older TL-SDUs 
that are not yet completely received or that have not yet been acknowledged as completely received. It 
may include an acknowledgement block for newer TL-SDUs. If the acknowledgement blocks do not fit 
within one MAC block, then it may send multiple AL-ACK (or AL-RNR) PDUs. 

if the data sending entity does not receive an acknowledgement message either AL-ACK or AL-RNR PDU 
within acknowledgement waiting time T.252, then: 

if the window size for TL-SDU N.272 is fully used, then the sending LLC shall repeat its 
acknowledgement request as above by using the oldest AL-DATA-AR or AL-FINAL-AR PDU as 
appropriate, for which there is no received acknowledgement; or 

if the SDU window size for TL-SDU N.272 is not fully used, then the sending LLC may continue its 
transmission by using AL-DATA(-AR) or AL-FINAL(-AR) PDU as appropriate. 

NOTE: The sending entity may continue data transmission within TL-SDU window 
independently of the acknowledgement waiting timer. 

22.3.3.2.4 TL-SDU re-transmission 

In the case all the segments of a TL-SDU have been received, but the FCS verification has failed, the 
whole TL-SDU shall be re-transmitted if within the allowed number of TL-SDU re-transmissions N.273. 
The receiver shall indicate the FCS failure by setting value 111111 2 to the acknowledgement length 
information element in the AL-ACK or AL-RNR PDU. On the transmitter side, this TL-SDU shall be 
re-transmitted using the same TL-SDU discriminator and starting transmission from the first segment. 

Refer to subclause 22.3.3.2.6 for reasons of the sending entity to re-transmit a TL-SDU. 

If the maximum number of TL-SDU re-transmission N.273 is exceeded, the sending LLC shall abandon 
the transmission of that TL-SDU and report an error to the service user using a TL-REPORT indication 
"failed transfer". The service user should stop to use the advanced link and either reset or disconnect it, 
refer to subclauses 22.3.3.1 .1 and 22.3.3.3 for protocol actions. 
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22.3.3.2.5 Flow control 

During the transmission in an advanced link, the receiving entity has the possibility to interrupt the 
transmitting entity from sending new TL-SDUs. The receiving entity shall use as acknowledgements either 
an AL-ACK or an AL-RNR PDU, if the receiver may continue to receive more data or is not capable of 
receiving more data respectively. The AL-RNR PDU shall also acknowledge already received PDUs and 
or segments of PDUs. 

When an AL-ACK or AL-RNR PDU is sent over the air interface, it shall reflect the actual situation at the 
receiver at the transmission time of this acknowledgement. 

Upon reception of an AL-RNR PDU the transmitting entity shall wait until either the peer entity sends an 
AL-ACK PDU or the receiver not ready validity timer for the sending entity T.271 expires (or until the link 
is disconnected or reset). The sender may continue sending of those TL-SDUs, which are partially 
acknowledged in the AL-RNR PDU or previously. The receiving entity may need to send more than one 
AL-RNR PDU, when there is more segments or PDUs waiting for positive or negative acknowledgement 
than fits into one AL-RNR PDU. 

If the receiver not ready validity timer for sending entity T.271 expires, the sending entity shall try to start 
the sending of the TL-SDUs from the first unacknowledged PDU if there is still room in the TL-SDU 
sending window N.272, or from the last segment of the last already acknowledged TL-SDU, if there is no 
room in the TL-SDU window. If the receiving LLC cannot accept the new TL-SDU, it shall acknowledge the 
last already received and acknowledged TL-SDU by a AL-RNR PDU. 

During the receiver not ready validity timer for the receiving entity T.272 the receiving entity may re-issue 
an AL-RNR to indicate the continuation of the incapability to receive new TL-SDUs. 

22.3.3.2.6 Actions on TL-DATA request (sending entity) 

During acknowledged data transfer the LLC sending entity may receive (in state "AL_TX_READY") from 
the service user: 

a) a TL-DATA request primitive and then: 

i) the sending LLC shall issue a TL-REPORT indication (handle) to the TL-DATA request; 

ii) the LLC shall calculate the FCS and append it to the TL-SDU; 

iii) save the TL-SDU with the FCS into sending buffer and inform the MAC layer how much data 
is available for sending by the DATAJN_BUFFER signal, see subclause 22.3.1 .7.2; 

local indications: 

b) MAC-READY signal and then: 

if there no segments pending for re-transmission, the LLC shall format a new segment of the 
TL-SDU in the sending buffer as defined in subclause 22.3.3.2.1 and issue it to the formatter 
and set the corresponding segment re-transmission counter; 

if there is at least one segment pending for re-transmission and the maximum number of 
segment re-transmissions N.274 of that segment is not exceeded, then the LLC shall select 
the oldest segment, for which there is a re-transmission request pending and issue the PDU 
to the formatter; 

if there is at least one segment pending for re-transmission and the maximum number of the 
segment re-transmissions N.274 of that segment is exceeded but the maximum number of 
TL-SDU re-transmissions N.273 is not exceeded, then the LLC shall start re-sending of the 
complete TL-SDU and form a new starting segment of that TL-SDU and issue it to the 
formatter; 

if there is at least one segment pending for re-transmission and both the maximum number 
of segment re-transmissions N.274 of that segment and the maximum number of TL-SDU re- 



Page 426 

ETS 300 392-2: March 1996 

transmissions N.273 are exceeded, then the LLC shall inform the service user about TL-SDU 
transmission failure by a TL-REPORT indication primitive (failed transfer); 

c) an indication, that the acknowledgement waiting timer T.252 has expired, refer to acknowledgement 
mechanisms in subclause 22.3.3.2.3 for actions; 

d) a TMA-REPORT indication (handle), which the LLC shall memorise; 

e) a TMA-REPORT indication (successful complete transmission by random access or complete 
transmission by reserved access or stealing) and if it is a response to either a AL-DATA-AR or 
AL-FINAL-AR PDU the LLC shall start acknowledgement waiting timer T.252; 

f) a TMA-REPORT indication (random access failure) and then the LLC shall inform the service user 
by a TL-REPORT indication primitive (failed transfer) and the LLC shall delete the TL-SDU from the 
sending buffer; 

NOTE 1 : After a failed transfer attempt (see b) and f) above) the service user should 
immediately either reset or disconnect the advanced link, which should be no more 
useable in the current state. 

PDUs from peer entity: 

g) an AL-ACK PDU either to acknowledge received segments and/or TL-SDUs or to indicate that the 
peer entity is capable to receive more data, refer to subclause 22.3.3.2.3 for the actions on the 
acknowledgement; 

h) an AL-RNR PDU to acknowledge received TL-SDUs and/or segments and to indicate that the peer 
entity is currently not capable to receive more data, refer to flow control in subclause 22.3.3.2.5. 

NOTE 2: In this subclause word segment is used instead of AL-DATA, AL-DATA-AR, AL-FINAL 
and AL-FINAL-AR PDUs, refer to segmentation in subclause 22.3.3.2.1 and 
acknowledgement in subclause 22.3.3.2.3 for selection of the correct PDU. 

22.3.3.2.7 Data reception from the peer entity (receiving entity) 

When advanced link LLC receiving entity is ready for receiving data (in the state "AL.RX.READY"), it may 
receive: 

local indications: 

a) MAC-READY signal and then the LLC shall send the AL-ACK or AL-RNR PDU as appropriate, see 
later in this subclause and in subclause 22.3.3.2.3 for the acknowledgement procedure; 

PDUs from the peer entity: 

b) AL-DATA or AL-FINAL PDU and then the LLC shall store segment into the correct position for 
reassembling in the corresponding TL-SDU and shall check completeness and correctness of the 
received TL-SDU; and 

if the TL-SDU is completely and correctly received the LLC shall mark it received and ready 
for acknowledgement; and 

if the number of the TL-SDU (N(S)) is the lowest SDU in the receiver window the LLC shall 
update the lower window boundary and deliver the received TL-SDU to the service user in a 
TL-DATA indication; or 

if all segments of that TL-SDU are received, but the FCS calculation fails, then the LLC shall 
discard that PDU and mark that it needs to be re-transmitted; 
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c) AL-DATA-AR or AL-FINAL-AR PDU and then the LLC shall store segment into the correct position 
for reassembling in the corresponding TL-SDU and shall check completeness and correctness of 
the received TL-SDU; and 

if at least one new TL-SDU is completely and correctly received (FCS matches) the LLC shall 
mark it received and prepare either AL-ACK or AL-RNR PDU as defined in 
subclause 22.3.3.2.5 with a possible bitmap of the unacknowledged segments in the other 
SDUs t inform the formatter by the DATAJN_BUFFER signal and if the number of the 
TL-SDU (N(S)) is the lowest SDU in the receiver window the LLC shall update the lower 
window boundary and deliver the received TL-SDU to the service user in a TL-DATA 
indication; 

if all segments of that TL-SDU are received, but the FCS calculation fails, then the LLC shall 
discard that PDU and prepare either AL-ACK or AL-RNR PDU asking re-transmission of that 
TL-SDU, with a possible bitmap of the unacknowledged segments in the other SDUs and 
inform the formatter by the D ATAJ N_BU FFE R signal; 

if no TL-SDU is received correctly, then the LLC shall mark the segment received and 
prepare either AL-ACK or AL-RNR PDU, with a bitmap of the unacknowledged segments in 
this and possibly other SDUs and inform the formatter by the DATA_IN_BUFFER signal; 

The LLC shall use priority level = 5 and allow frame stealing for a response to an AL-DATA-AR or 
AL-FINAL-AR PDU (though in most cases neither of these parameters will actually be used in the 
MAC, since AL-ACK and AL-RNR are usually sent by reserved access). 

indication from the service user: 

d) a FLOW-NOT-READY signal and then the LLC shall prepare an AL-RNR PDU, with a possible 
bitmap of the unacknowledged segments in the received SDUs and inform the formatter by the 
DATAJN_BUFFER signal; 

e) a FLOW-READY signal and then the LLC shall prepare an AL-ACK PDU, with a possible bitmap of 
the unacknowledged segments in the received SDUs and inform the formatter by the 
DATA_IN_BUFFER signal, refer to flow control in subclause 22.3.3.2.5. 

NOTE 1 : The receiving process delivers TL-SDUs in the sequence defined by the N(S). 

NOTE 2: If it receives any of the data transfer PDUs (AL-DATA, AL-DATA-AR, AL-FINAL or 
AL-FINAL-AR), when the corresponding advanced link is no more in "RX_READY" 
state, then the PDU will be discarded in this model by the formatter without any further 
actions. 

NOTE 3: When the LLC receiving entity has completely and correctly received a TL-SDU, and if 
the number of the TL-SDU is the lowest in the receiver window, then the LLC updates 
the lower window boundary and delivers the received TL-SDU to the service user. 
However, even when the LLC has sent an acknowledgement for the correctly received 
TL-SDU, that acknowledgement may not have been received by the sending entity. 
Therefore the LLC may still receive AL-DATA(-AR) and AL-FINAL(-AR) PDUs for the 
N.272 TL-SDUs below the current receiver window. If this occurs, the receiving LLC 
should discard the received segment(s) but should send an acknowledgement to 
indicate that the TL-SDU has been correctly received. 

22.3.3.3 Release of acknowledged service advanced link 

In the advanced link the end of the transfer shall be notified by AL-DISC PDU with reason "close". In the 
acknowledged data transfer the disconnection shall be confirmed by sending a AL-DISC PDU with reason 
"success". Disconnection may occur at any time. When the receiving entity recognises a disconnect it 
shall delete all partially received TL-SDUs. 
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22.3.3.3.1 Actions on TL-DISCONNECT request (MS sending entity) 

Upon reception of a TL-DISCONNECT request in state WAIT_OUT_CONNECT or CONNECTED, the 
LLC shall: 

i) prepare an AL-DISC PDU with reason "Close" and inform the formatter by D ATAJ N_BU FFER 
signal; 

ii) set re-try counter to allow the maximum number of connection disconnect retries N.263; 

iii) cease all sending and receiving any data and discard all TL-SDUs waiting for sending or which are 
partially received on this advanced link and start to wait in "WAIT_DISCONNECT" state. 

In the "WAITJDISCONNECT" state the LLC may receive: 

local indications: 

a) a MAC-READY signal and then the LLC shall issue the AL-DISC PDU to the formatter; 

b) a TMA-REPORT indication (successful complete transmission by random access or complete 
transmission by reserved access or by stealing) and then the LLC shall start the disconnection 
waiting timer T.263; 

c) a TMA-REPORT indication (random access failure) and then the LLC shall inform the service user 
by a TL-DISCONNECT confirm (random access failure) and go into the "IDLE" state; 

d) an indication of the expiry of the disconnection waiting timer T.263 and: 

if more retries (N.263) are available, then the LLC shall issue the previous AL-DISC PDU into 
the transmission buffer and inform formatter by the DATAJN_BUFFER signal; 

if all retries (N.263) are used, then the LLC shall inform the service user by a TL- 
DISCONNECT confirm (disconnection failure) and go into the "IDLE" state; 

a PDU from the peer entity: 

e) an AL-DISC PDU with reason "Success", then the LLC shall inform the service user by a 
TL-DISCONNECT confirm and go into "IDLE" state; 

f) an AL-DISC PDU with reason "Close", then the LLC shall deliver an AL-DISC PDU with reason 
"Success" to the formatter as a response to the next MAC-READY signal and go into "IDLE" state. 

22.3.3.3.2 Actions on AL-DISC PDU reception (MS receiving entity) 

While being ready for data transfer the advanced link LLC may receive: 
a PDU from the peer entity: 

a) an AL-DISC PDU with reason "Close" and then: 

i) the LLC shall stop sending and receiving any data and discard both TL-SDUs waiting for 
sending and TL-SDUs, which are partially received of fully received; 

ii) prepare an AL-DISC PDU with a reason "Success" and inform the formatter by the 
DATAJNJBUFFER signal; 

iii) indicate to the service user the removal of the advanced link using a TL-DISCONNECT 
indication primitive "incoming disconnection"; 

local indications after preparing an AL-DISC PDU: 

b) a MAC-READY signal and then the LLC shall issue the AL-DISC PDU to the formatter; 



Page 429 
ETS 300 392-2: March 1996 

c) a TMA-REPORT indication (successful complete transmission by random access or complete 
transmission by reserved access or by stealing) and then the LLC shall go into "IDLE" state; 

d) a TMA-REPORT indication (random access failure) and then the LLC shall go into the -IDLE" state. 

When the LLC receives in the "IDLE" state an AL-DISC PDU with reason "Close", the LLC shall deliver an 
AL-DISC PDU with reason "Success" to the formatter as a response to the next MAC-READY signal. 

NOTE: A MS may receive an AL-DISC PDU also in other states of the LLC protocol, refer to 
advanced link establishment actions. 

22.3.3.4 Abnormal release of advanced link 

While in any state the advanced link LLC may receive: 

a) a TL-RELEASE request primitive from the service user and then the LLC shall close the advanced 
link without any signalling with the peer entity and go to "IDLE" state; 

b) a TMA-RELEASE indication primitive and then the LLC shall close the advanced link without any 
signalling with the peer entity, indicate link disconnection to the service user by a TL-DISCONNECT 
indication with a reason "local disconnection" and go to "IDLE" state. 

22.3.4 Advanced link procedures for unacknowledged service 

The unacknowledged service uses the same mechanisms for sequencing, segmentation and 
re-assembling as the acknowledged service (see subclauses 22.3.3.2.1 and 22.3.3.2.2). The window size 
for TL-SDU in unacknowledged service N.281 defines how many TL-SDUs may be in transit at the same 
time. The numbering of TL-SDUs N(S), contrary to the acknowledged service, may start at any value. 

22.3.4.1 Advanced link unacknowledged service establishment 

The BS should established the unacknowledged service before it starts to send data. 

The BS should start unacknowledged data transfer by sending one or more AL-SETUP PDUs. During 
unacknowledged data transfer the BS may repeat the AL-SETUP PDU using current value for the TL-SDU 
number N(S) to re-synchronise receiving MSs. The TL-SDU numbering may start at any value to allow re- 
setting of an unacknowledged service without re-setting the TL-SDU window position. After the reception 
of a AL-SETUP PDU the TL-SDU window lower edge shall be the TL-SDU number N(S) and the upper 
edge shall be N(S) + N.281 - 1 (Window size for TL-SDU in unacknowledged service). After sending an 
AL-SETUP PDU the BS should not repeat any TL-SDU or segments of those having a TL-SDU sequence 
number lower than the one (N(S)) indicated in the AL-SETUP PDU. 

22.3.4.2 Reception of unacknowledged service data 

The LLC MS entity may receive at any state: 

a) an AL-SETUP PDU for unacknowledged information reception and then the LLC shall deliver an 
TL-CONNECT indication to the service user and shall empty possible current buffer, prepare a new 
buffer for data reception, inform the service user by a TL-CONNECT indication (unacknowledged 
service) and start to wait for data in the state "AL_UNACK_READY"; 

b) an AL-DISC PDU and then the LLC shall discard all partially received TL-SDUs and may deliver an 
TL-DISCONNECT indication to the service user. 

While in the " AL„U N AC K_R E AD Y" state the MS LLC may receive an AL-UDATA PDU or an AL-U FINAL 
PDU; and 

if the corresponding TL-SDU is not earlier delivered to the service user, then the LLC shall store the 
segment into correct position of the relevant TL-SDU as indicated by N(S) and S(S) elements 
respectively; and 

if a TL-SDU is now completely and correctly received, then the LLC shall deliver the TL-SDU to the 
service user in a TL-UNITDATA indication primitive and mark the TL-SDU as received. 
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NOTE 1 : The MS LLC may deliver the received TL-SDUs out of sequence. 

NOTE 2: The advanced link protocol allows suppression of received duplicates. 

Each time the LLC receives an AL-UDATA or an AL-U FINAL PDU the LLC shall upgrade the receiving 
window upper edge to the received N(S) if it is higher than the current upper edge and calculate a new 
lower edge. The LLC shall then check if there are any partially received TL-SDUs, which have TL-SDU 
number outside the new receiving window and then the LLC shall discard those partially received SDUs. 

NOTE 3: An AL-SETUP PDU for unacknowledged information reception (or an AL-UDATA or 
AL-UFINAL PDU) may be sent in a group addressed MAC PDU that contains a 
channel allocation. If the MS-MAC requires instruction on whether to accept the 
channel allocation, then it sets the "channel change response required" parameter to 
"true" in the TMA-UNITDATA indication primitive. If the MS decides to accept the 
channel allocation then the higher layers should issue a CONFIGURE request primitive 
to the MAC containing the "channel change accepted" parameter. 

22.3.4.3 Sliding SDU window in unacknowledged service 

The BS LLC should send unacknowledged data using a TL-SDU window size of 1 to the maximum N.281. 
This means that the BS LLC may transmit with all repetitions up to N.281 different TL-SDUs at any time. 
When all repetitions of the lowest numbers TL-SDU are completed, then the BS LLC may start to send a 
new TL-SDU. The BS LLC informs the TL-SDU window size at the establishment of the advanced link by 
sending one or more AL-SETUP PDUs. 

22.3.4.4 Disconnection of unacknowledged data transfer 

The BS may disconnect an unacknowledged service by sending one or more AL-DISC PDUs. When the 
MS receives an AL-DISC PDU is shall discard all partially received TL-SDUs and cease reception of all 
AL-UDATA PDUs. 

23 MAC protocol 

This clause describes the V+D air interface layer 2 MAC protocol. It defines the operation of the MAC 
layer in the MS and includes some corresponding rules for the operation of the BS. However, the exact 
rules for how the BS allocates resources to MSs are outside the scope of this ETS. 

See ETS 300 392-1 [11], clause 6 for the general architecture and a description of all layers including the 
functionality of the MAC sub-layer (see clause 19 for the architecture of the DLL). MAC timers and 
constants are defined in annex B. 

23.1 MAC services 

23.1.1 Functions of MAC 

In the protocol model, internal communication between the LLC and the MAC uses three SAPs TMA-SAP, 
TMB-SAP and TMC-SAP, corresponding to signalling, broadcast and layer management functions 
respectively. A fourth SAP, the TMD-SAP, supports traffic in circuit mode; this service is offered directly 
from the MAC to the U-plane application (e.g. the CODEC). 

The MAC itself is divided into two sub-layers, the upper and lower MAC. 

The lower MAC performs the channel coding and interleaving, as described in clause 8. The upper MAC 
performs the other MAC protocol functions and is described in this clause. Unless specified otherwise, 
references to "the MAC" in this clause mean the upper MAC. 
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The principal functions of the upper MAC are as follows: 
frame and multiframe synchronisation; 
multiplexing/de-multiplexing of the logical channels; 

radio path establishment and channel allocation (for common control channels and for assigned 
channels); 

address management for the layer 2 address (the source address for the uplink, the destination 
address for the downlink); 

fragmentation of long messages received from the LLC (subdividing the LLC message between 
more than one MAC block); 

association of short messages received from the LLC (enabling more than one message to be sent 
within one MAC block); 

management of power control; 

the random access procedure (contention control); 

granting and use of reserved slots: non-contentious slots reserved by the BS for one MS to send 
signalling message(s); 

path loss calculation: surveillance of the serving cell, and monitoring and scanning of adjacent cells; 
energy economy operation ; 

providing service to circuit mode applications (e.g. speech CODEC or circuit mode data); 
stealing from the traffic channel capacity, when required, to send signalling messages. 
23.1 .2 Service primitives 

The MAC protocol is described in terms of primitives and valid sequences of actions resulting from those 
primitives. Refer to clause 20 for a detailed description of the service primitives. 

The use of primitives in this clause refers to the protocol definition, but does not imply any implementation. 
The MAC boundary, as for other internal boundaries, is defined to clarify the protocol description. The 
word "shair is used to describe the SAPs and primitives for traceability reasons in the protocol model, but 
those SAPs and primitives are not testable. 

23.1 .2.1 Service at the TMA-SAP 

The TMA-SAP shall be used for the transmission of signalling and packet data information over the air 
interface. Service data units, TM-SDUs, shall be transferred to and from the LLC using the 
TMA-UNITDATA primitive. (The TM-SDU is the LLC PDU, including the LLC header and optional FCS). 

The TMA-UNITDATA request from LLC to MAC shall be used when the LLC wishes to send data to 
the peer entity. 

The TMA-UNITDATA indication from MAC to LLC shall be used to deliver data received from the 
peer entity. 

The MAC in the MS (MS-MAC) shall report the progress of a request procedure locally to the LLC using 
the TMA-REPORT indication primitive. The LLC may abort a TMA-UNITDATA request using the 
TMA-CANCEL request primitive. 

The random access protocol is generally needed when the MS sends a message to initiate a call or 
transaction. However, when an MS is required to send a solicited message or when it has further 
signalling to send after the initial access, the BS may reserve slots for that particular MS. This enables a 
higher channel throughput to be achieved. 
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On a control channel, MSs may transmit only by random access or reserved access. Whereas, during a 
circuit mode call, the transmitting MS may "steal" from the traffic channel capacity to send signalling 
messages. 

The signalling service offered by the MS-MAC to the LLC shall be an unacknowledged service in the case 
of non-contentious transmission (i.e. reserved access or stealing). The MAC receives a TM-SDU from the 
LLC, transmits the TM-SDU (in one or more MAC blocks) and then reports to the LLC when the message 
has been sent. Acknowledgements and re-transmissions are under the control of the LLC. 

However, for contentious access (i.e. random access), the MS-MAC is responsible for sending retries until 
it receives a MAC response from the BS indicating successful random access. The report to the LLC shall 
then indicate that the BS has acknowledged the random access message. 

TMA-SAP signalling messages may generally be sent using the MAC-RESOURCE PDU for the downlink, 
or the MAC-ACCESS PDU (in a subslot) or MAC-DATA PDU (in a full slot) for the uplink. A general 
scenario for an exchange of two LLC messages is shown in figure 138. (Other PDUs, MAC-FRAG and 
MAC-END(-HU), shall be used for continuations and end of a fragmented TM-SDU). 

The uplink MAC-ACCESS and MAC-DATA PDUs shall include the layer 2 address and usually carry a 
TM-SDU; they can also be used to request reserved slots for signalling messages. On the downlink, the 
MAC-RESOURCE PDU usually includes layer 2 addressing and may contain a TM-SDU. The 
MAC-RESOURCE PDU may also include elements for granting reserved slots and/or for channel 
allocation and/or for power control. The MAC PDUs are defined in clause 21 . 



TMA-UNITDATA 
request 



TMA-UNITDATA 
indication 



TMA-UNITDATA 
request 



MS-MAC 



MAC-RESOURCE PDU 



MAC-ACCESS PDU 
or MAC-DATA PDU 



TMA-UNITDATA 
indication 



BS-MAC 



Figure 138: Scenario for exchange of two LLC messages 



23.1.2.1.1 Reports 

When the MS-MAC receives a TMA-UNITDATA request primitive from the LLC, it shall generate a local 
identifier for the service request, referred to as the "Handle to the request", and shall immediately give this 
handle to the LLC (using the TMA-REPORT indication primitive). The handle should be retained locally 
and used for routing subsequent reports. It refers to all actions required in the MAC to accomplish the 
request. 

The MS-MAC shall issue further reports to the LLC at the following times: 

i) first transmission of complete TM-SDU by random access; 

ii) when the BS acknowledges reception of a complete TM-SDU sent by random access; 

iii) complete TM-SDU (or final fragment of a fragmented TM-SDU) has been sent by reserved access 
or by stealing; 

iv) random access failure; 

v) failure of fragmentation process (TM-SDU not completely sent). 

In the case of a TMA-CANCEL request, the MS-MAC shall report whether or not the TM-SDU has been 
completely sent. 

After sending reports ii), iii), iv), v), or after cancellation, the MS-MAC shall regard the requested 
procedure as complete. The MS-MAC shall discard the TM-SDU and the handle becomes invalid. 



Page 433 

ETS 300 392-2: March 1996 

23.1 .2.1 .2 Buffering mechanism 

When the MS-MAC receives a downlink PDU addressed to that MS or to a group of which that MS is a 
member, it shall immediately deliver any TM-SDU to the LLC using the TMA-UNITDATA indication, except 
in the case of a fragmented message, when the MS-MAC shall reconstruct the entire TM-SDU before 
delivering it to the LLC. 

For an MS sending PDUs, there may be many messages to be sent. For the purposes of the protocol 
description, it is assumed that the layer 2 queue of messages is held in the LLC and that the MAC has a 
sending buffer only. 

According to this protocol description, there shall be two related signals between MS-MAC and MS-LLC. 

i) DATA-IN-BUFFER signal from LLC to MAC. 

This shall indicate the total amount of outstanding individually addressed signalling data that the 
LLC has ready to send for a particular endpoint identifier, i.e. control channel, and not yet given to 
the MAC. 

It shall also indicate the maximum values of the PDU priority and stealing permission parameter for 
the messages in the LLC queue for that channel. These parameters enable the MAC to decide on 
the appropriate means to transfer the information before receiving the actual service request. 

ii) MAC-READY signal from MAC to LLC. 

This signal shall be issued to the LLC when the MS-MAC is ready to send a MAC block. 

It shall indicate the maximum size of TM-SDU that can be carried within the MAC PDU that the 
MS-MAC intends to send, i.e. the maximum size without requiring fragmentation. 

It shall also indicate the absolute maximum size of TM-SDU that can be handled in the MAC at this 
time. This is normally the maximum size of fragmented TM-SDU (up to N.202 bits), but shall be 
reduced in the case of stealing to either the size of the MAC block or to the capacity of two half slots 
if two-half-slot stealing is appropriate at this time. 

On receipt of the MAC-READY signal, the LLC will usually issue a TMA-UNITDATA request primitive to 
the MAC, (see also clause 22). 

23.1 .2.1 .3 Usage of signals 

This subclause describes the usage of the MAC-READY and DATA-IN-BUFFER signals. The actual MAC 
procedures for fragmentation, association, random access, reserved access and stealing are described 
later in this clause. The procedures a), b) and c) below relate to the protocol model of the interface with 
the LLC and do not imply any implementation. 

a) Random access 

If the DATA-IN-BUFFER signal from the LLC indicates that there is data to send, and if the 
MS-MAC has neither been granted any reserved slots nor asked for reserved slots, then the 
MS-MAC should prepare to initiate the random access procedure. The MS-MAC shall issue the 
MAC-READY signal to the LLC, indicating the available size of TM-SDU within the MAC-ACCESS 
PDU 

i) 



ii) 



If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that fits within 
the MAC block then the MAC-ACCESS PDU shall carry that TM-SDU. If there is still space 
within the MAC block for another PDU by association, the MS-MAC may repeat the 
MAC-READY/TMA-UNITDATA exchange process as required until there is not space for 
another MAC header. 

If the LLC issues a TMA-UNITDATA request primitive containing a TM-SDU that does not fit 
within the MAC-ACCESS PDU, then the MAC-ACCESS PDU shall carry a first fragment of 
the TM-SDU using the fragmentation procedure and including a request for reserved capacity 
within the MAC-ACCESS PDU. 



Page 434 

ETS 300 392-2: March 1996 



iii) If the LLC does not issue a TMA-UNITDATA request primitive then the MAC-ACCESS PDU 
shall contain a request for reserved capacity but shall not carry a TM-SDU. This case may 
arise if the LLC has only full-slot advanced link messages to send at this time. 

NOTE 1 : The maximum available size of TM-SDU in the MAC-ACCESS PDU is variable, 
depending on whether the MS requests reserved capacity for further signalling. 

b) Reserved access 

When the MS-MAC has a reserved slot, or subslot, individually granted to it by the BS then, if it is 
already in the process of sending a fragmented TM-SDU, it shall send the next fragment. Or, if 
there is no data in the LLC buffer, the MS-MAC shall send the Null PDU. Otherwise, just before the 
transmission is due, the MS-MAC shall issue the MAC-READY signal to the LLC, announcing the 
maximum available size of TM-SDU in this MAC-DATA, or MAC-ACCESS, PDU. 

Then procedures i), ii) and iii) above generally apply except that the appropriate PDU for a full slot is 
MAC-DATA, and case iii) should not occur for a full slot grant. 

NOTE 2: The timing of the MAC-READY signal should be as late as possible, to allow the 
maximum time if the layer 3 in the MS is preparing a response to a BS message. 

c) Stealing 

When the MS is transmitting in a circuit mode call, and if there is data in the LLC buffer for which 
the stealing permission parameter indicates that stealing may be used, then the MS-MAC shall 
issue the MAC-READY signal to the LLC indicating: 

the size of TM-SDU in this MAC block; and 

the maximum valid size of TM-SDU, given any current stealing limitations. 

The fragmentation and association mechanisms may apply as described above. If the LLC does not 
issue a TMA-UNITDATA request primitive, for example because the message is too long, then the 
MS-MAC shall not perform the stealing but may use the TMA-SAP procedures, random access 
and/or reserved access, to send the messages in the LLC buffer. 

23.1 .2.1 .4 Priority and subscriber class 

The TMA-UNITDATA request primitive includes the layer 2 priority of the message, the stealing 
permission parameter and the subscriber class parameter. And the DATA-IN-BUFFER signal indicates 
the maximum priority and stealing permission parameter in the LLC queue. The MS-MAC shall use these 
parameters as follows: 

i) the MS-MAC may need to use the priority and subscriber class parameter from the 
TMA-UNITDATA request in the random access procedure, if the BS has announced priority or 
subscriber class restrictions on random access at this time; 

ii) the priority from the DATA-IN-BUFFER signal may also be used to cut short the reserved access 
waiting time-out if there is an emergency message in the LLC buffer, so that the MS may initiate the 
random access procedure; 

iii) the stealing permission parameter may be used to trigger the stealing mechanism. 

There are eight possible levels of the layer 2 PDU priority, from the lowest priority 0, increasing to the 
highest priority 7 corresponding to an emergency message. 

There are 16 possible subscriber classes, allowing a population subdivision, e.g. for random access 
control. The operator defines the values and meaning of each class, and the MS may belong to one or 
more of those classes. The subscriber class parameter, as supplied in primitives from the higher layers, is 
a bit mapped field which indicates, for each class, whether the MS belongs to that class. 
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The stealing permission parameter defines whether the MAC may use stealing to send this message, if 
the MS is currently transmitting traffic. It may have the following meanings: 

stealing not required; 

steal when convenient; 

steal within time T.214; or 

steal immediately. 

23.1 .2.2 Service at the TMB-SAP 

The TMB-SAP shall be used for the transfer of un-addressed system broadcast messages. The primitives 
shall be TMB-SYNC and TMB-SYSINFO. The request primitive shall be used in the BS. The indication 
primitive shall be used in the MS to deliver the TM-SDU to the higher layers. 

The corresponding PDUs shall be the SYNC and SYSINFO PDU, the content of BSCH and BNCH 
respectively. Both PDUs contain many MAC elements, and also include a TM-SDU used by the MLE. 

23.1 .2.3 Service at the TMC-S AP 

The TMC-SAP shall be used for the transfer of local layer management information. It provides no data 
transfer services over the air interface. It shall be used, for example, for the higher layers to instruct the 
MAC to reconfigure its parameters, for the MLE to direct monitoring and scanning procedures in the MAC 
and for the MAC to issue reports on progress. 

23.1 .2.4 Service at the TMD-SAP 

The TMD-SAP shall provide the interface between the MAC and the circuit mode U-plane application, e.g. 
the speech CODEC. It shall be used for the transfer of speech frames or circuit mode data. It shall also be 
used if the U-plane application steals from the traffic capacity to send encryption synchronisation 
information and/or user-to-user signalling messages. 

The TMD-UNITDATA request primitive from the U-plane application to the MAC shall be used when the 
U-plane application wishes to send data to the peer entity. 

The TMD-UNITDATA indication primitive from the MAC to the U-plane application shall be used to deliver 
data from the peer entity. 

There is also a TMD-REPORT indication, which shall be used by the MAC to issue reports to the U-plane 
application e.g. when the MAC has stolen capacity from the traffic channel. 

23.1 .2.5 Use of endpoint identifiers 

The MS-MAC receives the MCCH, or a common SCCH, unless directed by the BS to an assigned 
channel, assigned for a circuit mode call or for secondary control (see subclause 23.3). A common 
control channel comprises one timeslot per TDMA frame whereas an assigned channel comprises one or 
more timeslots per TDMA frame. It is optional for an MS to be capable of using a multi-slot channel. 

The MS may be capable of processing only one channel at a time, either a common control channel or an 
assigned channel. 

Other MSs may be capable of processing more than one channel simultaneously, allowing concurrent 
MAC services to be provided. The "endpoint identifier" is a local identifier used to distinguish between 
multiple concurrent service instances. 

At the LLC-MAC boundary, the endpoint identifier shall refer to the use of a particular MAC channel, 
common control channel or assigned channel. It identifies the channel to which a particular 
TMA-UNITDATA or TMD-UNITDATA primitive (or DATA-IN-BUFFER or MAC-READY signal) applies. 
There shall be a unique correspondence between the endpoint identifier and the physical channel 
allocation (timeslot or timeslots) used in the MAC. 



Page 436 

ETS 300 392-2: March 1996 



NOTE: A MAC channel may carry both the advanced link and basic link signalling. However, 
the MAC is not aware of any distinction between advanced link and basic link 
messages. 



23.1.3 



MS capabilities 



The following subclauses describe the capabilities of a frequency full duplex and half duplex MS. All MSs 
shall support frequency half duplex operation while an MS may also support frequency full duplex 
operation. 



23.1.3.1 



Frequency half duplex operation 



A frequency half duplex MS has the ability either to transmit on an uplink frequency or receive on a 
downlink frequency at any time. It is not able to transmit and receive at the same time. This type of MS 
also requires time to switch from its transmit to receive frequency. This shall be no more than a timeslot 
duration. 

Figure 139 shows the uplink and downlink slots of a single TDMA frame, with "x" marking an example of 
slots which can be used by a frequency half duplex MS. Only one downlink and the corresponding (same- 
numbered) uplink slot can be used in a single TDMA frame. If both the uplink and downlink slot in figure 
139 are used by a single MS, time division duplex operation can be realised allowing a frequency half 
duplex MS to support single slot duplex call services. 



Figure 139: Frequency half duplex operation 

In the example shown, the MS can receive the downlink slot and also transmit in the corresponding uplink 
slot. It is also possible for a frequency half duplex MS to operate with a multi-slot channel. However, in this 
case, the BS should not send signalling messages to that MS when the MS is transmitting traffic or 
transmitting in reserved slots. 



23.1.3.2 



Frequency full duplex operation 



A frequency full duplex MS has the ability to transmit on an uplink frequency and receive on a downlink 
frequency at the same time. Therefore, this type of MS can use all time slots in a TDMA frame. Figure 140 
shows the uplink and downlink slots of a single TDMA frame with "x" marking those slots which can be 
used by a frequency full duplex MS. Any combination of these slots may be used for a single call or for 
multiple calls. 



1 



Figure 140: Frequency full duplex operation 
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23.1 .3.3 Basic capabilities of the physical layer 

The following performance is expected from the physical layer for a TETRA MS. 

An MS shall be capable of changing from one frequency to another frequency in less than 1 timeslot 
duration. 

An MS shall be capable of changing from reception to transmission or from transmission to reception in 
less than 1 timeslot duration. 

An MS shall be capable of a combined frequency change and changing from reception to transmission or 
from transmission to reception in less than 1 timeslot duration. 

A frequency full duplex MS shall be capable of changing reception or transmission frequency (or both) in 
less than 1 timeslot duration. Frequency duplex operation is optional in the MS. 

An MS should be capable of receiving and decoding the AACH in contiguous timeslots. An MS may be 
capable of receiving or transmitting full slots of information in contiguous timeslots. 

23.2 Services provided by the lower MAC 

In the protocol model, the MAC layer is divided into two sub-layers, upper and lower MAC, as described in 
clause 19. The lower MAC shall provide the following services to the upper MAC protocol: 

transfer of MAC PDUs using suitable physical layer bursts in accordance with the chosen TDMA 
timeslot; 

report of PDU transfer related exceptions; 

signal strength measurement (i.e. RSSI); 

channel coding as described in clause 8: 

Forward Error Correction (FEC) and interleaving of MAC blocks; 
scrambling and de-scrambling of MAC blocks; 
CRC calculation; 

choice of training sequence and channel coding corresponding to the slot flag value and vice versa; 

control of the transmitted power, frequency, frequency band, duplex spacing and precise time 
synchronisation as described in clauses 6 and 10. 

The lower MAC provides these services to the upper MAC via the TMV-SAP. Tables 346 and 347 show 
the correspondence between service primitives at the TMV-SAP and the associated parameters 
respectively. 



Table 346: Correspondence between the upper and lower MAC at the TMV-SAP 



Upper MAC Service Primitive 


Lower MAC Service Primitive (TMV-SAP) 


TMA-UNITDATA request or 
TMB-SYNC request (BS only) or 
TMB-SYSINFO request (BS only) or 
TMD-UNITDATA request 


TMV-UNITDATA request 


TMA-UNITDATA indication or 
TMB-SYNC indication (MS only) or 
TMB-SYSINFO indication (MS only) or 
TMD-UNITDATA indication 


TMV-UNITDATA indication 
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Table 347: Parameters used in the TMV-UNITDATA primitive 



PARAMETER 


request 


indication 


MAC block 


M 


(=) 


MAC block length (note) 


M 


M 


Logical channel (note) 


M 


M 


CRC pass/fail indication (note) 




M 


Scrambling code (note) 


M 




Report (note) 




C 


NOTE: Not sent over the air interface. 



KEY: M: Mandatory; C: Conditional; (=): Equal to corresponding primitive; -: Not used. 

The TMV-SAP boundary is defined to clarify the protocol description and does not imply any MS 
implementation. The word "shall" is used to describe this SAP and the primitives for traceability reasons in 
the protocol model, but they are not testable. 

Many of the parameters exchanged at the TMV-SAP are not sent over the air interface but may be 
deduced from the physical layer transmission or reception. For example, the scrambling code is not sent 
as part of the information content, but modifies the information so that reception with a wrong scrambling 
code will generate an erroneous CRC and so the information will be discarded. On the contrary, reception 
with the correct scrambling code will only be affected by the transmission medium errors. 

The MAC block is the SDU from the upper MAC. The size of the MAC block shall be equal to the 
appropriate SDU size for the logical channel being used. For C-plane signalling, the upper MAC shall 
assure this size by fragmenting/associating suitably and by using the Null PDU and/or fill bits to make the 
MAC block up to the required size, e.g. the required size is 92 bits for SCH/HU, 268 bits for SCH/F and 
124 bits for STCH. For U-plane signalling on STCH, the MAC block shall comprise a single 
MAC-U-SIGNAL PDU. For TCH, the MAC block shall comprise a single MAC-TRAFFIC PDU, (for TCH/S, 
this PDU contains one or two speech frames and for circuit mode data, it contains data equivalent to a full 
slot). 

The scrambling code passed to the MAC by the MLE shall be a 24-bit field composed of the MCC and 
MNC as defined in ETS 300 392-1 [11], clause 7. The MCC and MNC shall be part of the MLE information 
contained within the SYNC PDU broadcast by the BS on the BSCH. The upper MAC shall add to this a 
6-bit colour code which shall be contained in the SYNC PDU. The combination of MCC, MNC and colour 
code shall make up the scrambling code which the upper MAC shall pass to the lower MAC via the 
TMV-SAP. This scrambling code shall correspond to the extended colour code used for scrambling and 
de-scrambling in the lower MAC as defined in clause 8. The scrambling code shall correspond to the 
30-bit extended colour code e(1), e(2),..., e(30) as shown in figure 141. 



10 bits 


14 bits 


6 bits 


Mobile Country Code (MCC) 


Mobile Network Code (MNC) 


Colour Code 


e(1)-e(10) 


e(11)-e(24) 


e(25) - e(30) 


e(1) = msb of MCC 


e(11) = msb of MNC 


e(25) = msb of Colour Code 



Figure 141 : Mapping of scrambling code to extended colour code 
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23.2.1 PDU mapping of the logical channels at the TMV-SAP 

Logical channel definitions are given in clause 9 and an overview of their use may be found in clause 19. 
Table 348 defines the mapping of the MAC PDUs defined in clause 21 onto the various logical channels. 



Table 348: Mapping of the MAC PDU onto the logical channels 



MAC PDU 


Logical channel(s) 


NOTE 


ACCESS-ASSIGN 


AACH 


MAC internal information 


ACCESS-DEFINE 


SCH/HD, SCH/F, STCH 




MAC-ACCESS 


SCH/HU 


TMA-SAP information 


MAC-END-HU 


SCH/HU 




MAC-DATA 


SCH/F, STCH 




MAC-RESOURCE 


SCH/HD, SCH/F, STCH 




MAC-FRAG 


SCH/HD, SCH/F 




MAC-END 


SCH/HD, SCH/F, STCH 




MAC-TRAFFIC 


TCH 


TMD-SAP information 


MAC-U-SIGNAL 


STCH 




SYNC 


BSCH 


TMB-SAP information 


SYSINFO 


BNCH 





23.3 Control channel usage 
23.3.1 Control channel types 

This subclause describes the MS procedures for using control channels. 
23,3.1.1 MCCH 

In each cell, one RF carrier shall be defined as the main carrier frequency which shall be broadcast in the 
SYSINFO PDU on the Broadcast Network Channel (BNCH). The MCCH shall occupy slot 1 of the main 
carrier frequency. An MS shall locate and receive the downlink MCCH, unless the BS has allocated any 
common SCCHs. 

The BS shall use SCH/HD, SCH/F, BNCH and BSCH for transmitting signalling and data messages on 
the downlink of the MCCH. An MS shall attempt to receive and decode any paging messages on the 
downlink MCCH addressed to that individual MS or to a group of which that MS is a member or to the 
group which includes all MSs on the system. An MS shall also attempt to receive and decode any 
broadcast signalling messages sent on the downlink of the MCCH. 

NOTE: Energy economy mode and the cell re-selection procedures may take precedence over 
the requirements on the MS to attempt to receive and decode paging messages and 
broadcast messages on the MCCH, or on a common SCCH. 

For uplink access on the MCCH, the MS shall follow the random and reserved access procedures 
described in subclauses 23.5.1 and 23.5.2 respectively. The MS shall use SCH/HU for random access on 
the uplink of the MCCH and SCH/HU or SCH/F for reserved access on the uplink of the MCCH. 

The MCCH shall not be extended to more than a single slot per frame. A BS in normal mode shall always 
have a MCCH. However, a BS may assign the MCCH for use as a traffic or assigned control channel in 
which case the BS enters minimum mode. 

The AACH in frames 1-17 shall indicate common control in the downlink direction for a MCCH. The 
contents of the AACH in frames 1-17 for the MCCH shall contain one of the following: 

a) header value = OO2: 

this is the normal case for an MCCH in which both the uplink and downlink are used for 
common control. "Field 1" shall indicate the random access parameters for subslot 1 and 
"field 2" the access parameters for subslot 2 of the uplink; 
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b) header value = 01 2 and "field 1 u = UMc (00001 0 2 ): 

the BS may assign the uplink of the MCCH as an assigned SCCH while still maintaining the 
MCCH on the downlink. In this case, the uplink may be shared between common control and 
assigned control. "Held 2" shall contain the random access parameters for both of the uplink 
subslots and shall apply to both common and assigned control random accesses; 

c) header value = 1 0 2 and "field 1" = UMc (00001 0 2 ): 

this is the same as for case (b) above except that the random access parameters in "field 2" 
shall apply only for MSs using the uplink for assigned control. Any MS in common control 
mode shall not use the uplink in this case; 

d) header value = 1 1 2 and "field 1" = UMc (00001 0 2 ) and "field 2" = UMt (xxxxxx 2 ): 

the BS may assign the uplink of the MCCH for transmission of traffic while still maintaining 
the MCCH on the downlink. "Field 2" shall contain the traffic usage marker for the uplink 
assigned channel. 

The AACH for frame 18 shall only indicate the uplink access rights. During normal mode operation, it shall 
always be assumed that slot 1 on the downlink is for common control as part of the MCCH. Any of the 
possible header values may be used during frame 18 for a MCCH. 

23.3.1.2 SCCH 

The BS may designate an SCCH for use as a MCCH by a subset of the user population. Alternatively, an 
SCCH may be allocated to certain MSs for subsequent data transfer. These two cases will subsequently 
be referred to as common and assigned SCCHs respectively. 

23.3.1 .2.1 Common SCCH 

The BS may operate up to three SCCHs for the purposes of common control signalling. Common SCCHs 
shall each occupy only one slot capacity on the main carrier and shall be used as the MCCH by a subset 
of the population. Therefore, a BS may operate up to a maximum of three common SCCHs in addition to 
the MCCH. 

The BS shall indicate the number of common SCCHs in operation on the main carrier by setting a two-bit 
field in the SYSINFO PDU transmitted on BNCH. This two-bit field maps to the number of common 
SCCHs in operation on this BS. If no common SCCHs are in operation, only the MCCH in slot 1 shall be 
available for common control signalling on the main carrier. If one common SCCH is indicated by the 
BNCH two-bit field, then slot 2 of the main carrier shall be used for this SCCH. If two SCCHs are in 
operation, slots 2 and 3 shall be used and if three SCCHs are in operation, slots 2, 3 and 4 shall be used. 

In idle mode, an MS shall receive either the MCCH (slot 1) or one of the common SCCHs on the main 
carrier. Therefore, an MS shall receive one of the four downlink slots on the main carrier for common 
control purposes. On registration or at subscription, an MS shall receive a parameter which indicates to 
the MS which one of the downlink slots on the main carrier shall be used. If an MS receives this value at 
subscription and then also is assigned a value at registration, the value given at registration shall be used. 
The following rule shall then be applied by the MS: 

N_SCCH = number of common SCCHs in operation: 

two-bit field transmitted by BS on BNCH, value = 0..3; 

MS_SCCH = MS SCCH allocation: 

four-bit field transmitted by BS to MS at registration or received by MS at subscription, 
value = 0.. 11 (eleven); 
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Main carrier downlink slot = 1 + (MS.SCCH mod (N_SCCH + 1)): 

value =1.. 4; 

mod = remainder after integer division. 

This rule shall enable the MS to derive the slot to be used on the main carrier from its MS_SCCH 
parameter received at registration or subscription and the number of common SCCHs currently in 
operation as indicated by the BS on BNCH. If the MS has not registered and has no value from 
subscription, it shall use the MCCH (i.e. slot 1 on the main carrier). 

The BS may change the number of common SCCHs by modifying the N_SCCH parameter. An MS shall 
decode the BNCH and recognise if N_SCCH has changed. If N_SCCH has changed the MS shall 
re-calculate, according to the above rule, the main carrier slot it should use for common control signalling. 
The BS shall not change its SCCH configuration before first transmitting the new configuration on the 
BNCH. 

A common SCCH, like the MCCH, shall always occupy only 1 slot per frame on the downlink of the main 
carrier. The uplink shall occupy only 1 slot per frame for reserved access but may use an extended uplink 
channel for random access purposes as indicated by the ACCESS-DEFINE PDU (see subclause 23.5.1. 
for more detailed explanation of random access procedures). 

An MS returning to the common control channel after, for example, a traffic channel assignment, shall 
return to the MCCH or SCCH it was using before the assignment unless it has received, in the meantime, 
BNCH indicating a change in the SCCH configuration. (An MS may return to the common control channel 
due to the MS deciding to leave the call or as a result of receiving a MAC-RESOURCE message with a 
Timeslot assigned" value of OOOO2 to indicate that it should go to the appropriate MCCH or common 
SCCH). In this case it shall return to the main carrier slot defined by the new configuration. The BS should 
transmit the BNCH in all slots of frame 18 before changing the SCCH configuration to ensure that all MSs 
including those on assigned channels receive the configuration change. 

The AACH for a common SCCH shall contain one of the combinations of elements (a-d) as described for 
the MCCH during frames 1-17 and shall follow the same rules defined for MCCH for frame 18. 

23.3.1 .2.2 Assigned SCCH 

A SCCH may be assigned by the BS for subsequent data transfer in response to an initial random access 
or after an initial paging message on the MCCH or on a common SCCH. This type of SCCH is referred to 
as an assigned SCCH. An MS shall be directed to an assigned SCCH by a MAC-RESOURCE PDU (see 
clause 21) transmitted by the BS. The assigned SCCH may be used by a certain group of MSs for a 
particular signalling message or data exchange (e.g. packet data); or it may be shared between several 
MSs each with intermittent bursts of signalling to send. 

NOTE 1: The BS may use an assigned SCCH as a general packet data channel supporting 
advanced links for several MSs, where each MS may be intermittently offering data 
packets. 

An assigned SCCH may be allocated as occupying up to four slots per frame as indicated by the 
MAC-RESOURCE PDU. If both the uplink and downlink are assigned for this purpose, they shall both 
occupy the same-numbered slots i.e. an assigned SCCH cannot be allocated with a different number of 
slots for the uplink and downlink. In addition, the number of slots allocated to a particular assigned SCCH 
by the BS may be increased or decreased by sending a MAC-RESOURCE PDU on the assigned SCCH. 

An MS shall attempt to receive and decode ail downlink signalling transmitted by the BS on all allocated 
slots of an assigned SCCH, within the constraints of the cell re-selection procedures. Similarly, the MS 
may transmit uplink signalling on all allocated slots of the uplink of an assigned SCCH in accordance with 
the random and reserved access procedures defined in subclauses 23.5.1 and 23.5.2 respectively. 

NOTE 2: The MS may operate with multi-slot channels without the need for the MS to support 
frequency full duplex. The MS capabilities are indicated in the mobile class ("class of 
MS" element, see clause 16). For an MS that is not frequency full duplex, and for a 
multi-slot channel, the BS should not send signalling messages to that MS when the 
MS is transmitting in reserved slots. 
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If the BS allocates an assigned SCCH on the downlink, the AACH in frames 1-17 shall contain a header 
value of 01 2( 10 2 or 11 2 and "field 1" shall be equal to UMa (000001 2 ). If the BS allocates an assigned 
SCCH in the uplink direction, the AACH in frames 1-17 shall contain a header value of 01 2 or 10 2 
depending on whether the uplink is also to be shared with common control uplink accesses. For a 
unidirectional assigned SCCH, any control slots in the opposite direction shall also be part of the assigned 
SCCH for the purposes of applying the general procedures for transmission and reception of signalling 
messages. 

If the BS allocates an assigned SCCH in both directions, the AACH in frames 1-17 shall contain a header 
value of 01 2 or 10 2 depending on whether the uplink is also to be shared with common control uplink 
accesses. 

The assigned slot(s) during frame 18 may used for any combination of common or assigned control 
signalling on the downlink and the AACH shall indicate the uplink access restrictions. 

The BS shall always transmit during the downlink slots of an assigned SCCH even while there is no 
signalling information to send. The BS may send broadcast PDUs or Null PDUs during these times. This is 
required in order for the MS to carry out correctly its channel maintenance procedures for an assigned 
channel. 

23.3.1.3 ACCH 

An ACCH is a control channel associated with an assigned traffic channel. There shall be two types of 
ACCH dependent on the current usage of the assigned channel. When the uplink or downlink of the 
assigned channel are not in use for traffic, the corresponding assigned slots in frames 1-18 shall be 
available for control signalling. This control channel is known as a Fast Associated Control Channel 
(FACCH). When the assigned channel is carrying traffic either in the uplink or downlink direction, only 
frame 18 is available for control signalling in that direction. This control channel is known as a Slow 
Associated Control Channel (SACCH). 

NOTE 1 : A traffic channel may be allocated as bi-directional but sometimes may only carry 
traffic either in the uplink or downlink direction e.g. for an inter-site call. Then the 
opposite direction is a FACCH. In this case, therefore, a FACCH will be available in 
one direction and a SACCH in the other direction. 

NOTE 2: When an assigned channel is carrying traffic either in the uplink or downlink direction 
then, in addition to the SACCH in that direction, capacity may be "stolen" from the 
circuit in frames 1-17 for signalling purposes, without changing the mode of operation, 
(see subclause 23.8). Stealing uses the STCH logical channel, whereas the FACCH 
and SACCH are mapped onto SCH. 

An ACCH shall have the same number of slots per frame as the associated traffic channel. The uplink and 
downlink shall have an equal number of slots per frame. Therefore, for a multi-slot traffic channel, the 
ACCH shall assume the same uplink and downlink slot allocation as assigned for the traffic channel. A 
receiving MS shall monitor all of the downlink slots of an ACCH to receive any addressed messages from 
the BS for that MS. An MS shall also receive any broadcast messages on the downlink ACCH. 

As an option, if the SwMI indicates that frame 18 extension is allowed (indicated by the "frame 18 
extension element" in the SYNC PDU), an MS may receive and decode PDUs on all four slots of frame 
18. However, the MS should not attempt to reconstruct any fragmented PDUs on frame 18 slots other 
than the SACCH for that MS. This restriction applies because an MS cannot know in which slot 
subsequent fragments will be sent for slots other than the SACCH for that MS. The MS shall not attempt 
to use random access transmission on slots of frame 18 other than its own SACCH. The application of the 
normal procedures for transmission and reception of signalling messages shall apply only to the SACCH 
(and FACCH) as indicated by the "timeslot assigned" element in the channel allocation. 

An MS transmitting in traffic mode shall receive and decode the SACCH in frame 18 as required by the 
assigned monitoring pattern. For multi-slot operation, the MS shall attempt to receive and decode at least 
the highest numbered downlink slot allocated for the circuit mode call in frame 18. The MS shall also be 
capable of transmitting in the highest numbered uplink slot in frame 18 in case it has to respond to paging 
message from the BS on the SACCH. 
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Similarly, an MS receiving in traffic mode shall attempt to receive and decode the lowest numbered slot 
allocated for the circuit mode call in frame 18 for SACCH downlink signalling and it shall be capable of 
transmitting uplink signalling during the lowest numbered slot in frame 18. This means that the MS can 
operate with multi-slot channels without the need for the MS to support frequency full duplex operation. 

When the MS switches out of traffic mode, it shall attempt to receive and decode all allocated slots for 
downlink FACCH signalling, within the constraints of the cell re-selection procedures. Similarly, any of the 
allocated slots may be used for uplink signalling in accordance with the MAC random and reserved 
access procedures. 

In the case of a downlink FACCH, the AACH shall contain a header value of 01 2 , 10 2 or 1 1 2 and "field 1" 
shall be equal to UMa (000001 2). In the case of an uplink FACCH, the AACH shall contain a header value 
of 01 2 or 10 2 depending on whether the uplink is also to be shared with common control uplink accesses. 

In the case of a bi-directional FACCH, the AACH shall contain a header value of 01 2 or 10 2 depending on 
whether the uplink is also to be shared with common control uplink accesses. 

The SACCH during frame 18 may used for any combination of common or assigned control signalling on 
the downlink and the AACH shall indicate the uplink access restrictions. 

The BS shall always transmit during the downlink slots of an ACCH even while there is no signalling 
information to send. The BS may send broadcast PDUs or Null PDUs during these times. This is required 
in order for the MS to carry out correctly its channel maintenance procedures for an assigned channel. 

23.3.1 .4 Monitoring pattern during multi -times lot operation 

The BS may allocate a multi-slot traffic channel for circuit mode data calls. A monitoring pattern shall be 
given by the BS along with the channel allocation at call set-up. A transmitting MS shall attempt to receive 
and decode downlink slots according to the monitoring pattern. This allows the BS to send signalling, for 
example using the STCH, to a transmitting MS. The MS shall only be expected to adhere to this 
monitoring pattern according to its duplex and switching capability. A BS should take this into account 
when attempting to transmit downlink signalling to a transmitting MS on a multi-slot channel. An MS 
transmitting on multiple slots per frame without a duplex or fast switching capability shall not be expected 
to receive signalling on the downlink in between transmitted bursts on the uplink. Therefore, the BS should 
only use frame 18 for signalling to that MS during transmission. 

23.3.2 Discontinuous transmission 

In the continuous mode of operation, the BS shall transmit continuously on the main carrier except during 
a BLCH. On the other carriers, the BS may ramp down and up during slots on the unused physical 
channels. However, the inter-slot training sequence, normal training sequence 3, shall always be present 
and so this ramping down and up is transparent to the MS operation. 

The BS shall indicate continuous or discontinuous operation by setting appropriately the "sharing mode" 
field broadcast in the SYNC PDU on the BSCH. Three modes of discontinuous transmission are defined: 

carrier sharing; 

MCCH sharing; and 

traffic carrier sharing. 

These modes are described in the following subclauses. 

Discontinuous operation on the main carrier may be used for the purposes of sharing the channel 
resources between a number of cells. It may be desired to allocate different slots on the main carrier to 
different cells. This is known as carrier sharing operation. Alternatively, it may be desired to share slot 1 of 
the main carrier between a number of cells. This is known as MCCH sharing. 

Discontinuous operation on carriers other than the main carrier may be used for the purposes of sharing 
traffic resources between a number of cells. This may apply if the BS uses either mode of discontinuous 
operation on the main carrier. Otherwise it may apply only to the carriers other than the main carrier. This 
is known as traffic carrier sharing. 
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It is optional for the MS to implement the methods for operating with a BS that uses any of the 
discontinuous modes. The MS shall not attempt to obtain service from a BS that uses a discontinuous 
mode unless that MS is capable of performing the appropriate procedures. 

23.3.2.1 Carrier sharing operation 

Carrier sharing operation allows the four slots of the main carrier to be shared between up to four adjacent 
cells. For example, each of four cells may be allocated one of the four time slots on the main carrier or 
each of two cells may be allocated two time slots each. Interference is avoided by ensuring that all of the 
cells sharing the carrier do not transmit on the downlink at the same time implying that the BSs sharing 
the main carrier need to be synchronised in time. 

If the slot allocated to a BS is for use as a control channel (main or common secondary), the BS shall 
transmit on the downlink in all frames for that slot. If the slot is for use as a traffic channel or assigned 
SCCH, the BS need not transmit on the downlink for that slot while it is not assigned. Indeed, a slot may 
be shared between a number of BSs for allocation as a traffic channel or assigned SCCH. 

The slot, frame and multiframe numbering may be independent between the cells sharing the main 
carrier. This means that all cells sharing a carrier can have a slot 1 for use as the MCCH for that cell. 

Carriers other than the main carrier may also be shared between adjacent cells. Therefore the MS 
designer should note that the BS may use discontinuous bursts on any of the carriers of a carrier sharing 
cell. 

23.3.2.2 MCCH sharing operation 

MCCH sharing allows a number of adjacent cells to share slot 1 of the main carrier for MCCH signalling. 
Up to 36 cells may share the same MCCH. Each cell has a number of reserved frames during which only 
the BS for that cell may transmit on the downlink MCCH. The remaining frames which are not reserved by 
any of the BSs sharing the MCCH may be used as common frames during which any of the BSs may 
transmit. However the network shall schedule downlink transmissions on common frames to ensure that 
two BSs do not transmit during the same common frame. 

If the SYNC PDU indicates "MCCH sharing", the SYNC PDU shall also indicate the number of reserved 
frames for this BS using the TS reserved frames" field. The "TS reserved frames" field shall indicate the 
number of frames reserved over two multiframe periods as defined in clause 9. The BS shall transmit on 
the downlink during these reserved frames. 

During this mode of operation, the BSs shall also broadcast the location of the common frames by using 
the TS_COMMON_FRAMES" field in the SYSINFO PDU sent on the BNCH. This field shall contain a bit 
map of the common frames for either the even-numbered or odd-numbered multiframes as indicated by 
the "Optional field flag". 

In order for this mode of operation to work successfully, the transmission of downlink bursts shall be 
synchronised in time between the BSs sharing the MCCH. In addition, slot numbering shall be 
synchronised between the BSs to ensure that they all have a common view of when downlink slot 1 is 
transmitted. However, frame and multiframe numbering shall be offset in order to avoid collision of bursts 
transmitted during reserved downlink slots. 

The remaining slots on the main carrier may be allocated as common SCCHs in which case the rules for 
reserved and common frames apply not only to slot 1 but also to those slots allocated as common 
SCCHs. Then the remaining slots not allocated for main or common secondary control may be shared 
between the BSs for use as traffic or assigned SCCHs. This sharing is performed on a carrier sharing 
basis, the rules for reserved and common frames do not apply to assigned channels. A BS need not 
transmit during these slots if they are not assigned. 

On a shared MCCH or common SCCH, the MS shall receive and decode the relevant slot during reserved 
frames for this BS and during those frames marked as common. It shall use the colour code received in 
the SYNC PDU on choosing a cell on which to camp in order to de-scramble the PDUs. This ensures that 
the MS cannot decode those transmissions during common frames on adjacent cells. In addition, the MS 
shall only use SYNC PDUs which contain the correct colour code for this cell since SYNC is not 
scrambled using the colour code meaning that an MS could receive SYNC from an adjacent cell. To 
prevent incorrect operation, only those with the correct colour code shall be interpreted by the MS. 
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Carriers other than the main carrier may be shared between adjacent cells (on a carrier sharing basis). 
Therefore the MS designer should note that the BS may use discontinuous bursts on any of the carriers of 
a MCCH sharing cell. 

23.3.2.3 Traffic carrier sharing operation 

Traffic carrier sharing allows the four slots of carriers other than the main carrier to be shared between 
adjacent cells. The BS shall transmit continuously on the main carrier (except during a BLCH). However, it 
may use discontinuous bursts on the other carriers. 

23.3.3 Minimum mode operation 

Minimum mode operation allows a BS to allocate all four timeslots of the main carrier for traffic or 
assigned control purposes. Therefore, only frame 18 is available for common control. The following 
subclauses describe the procedures for minimum mode operation which shall apply only to those MSs 
that are in common control mode and monitoring the MCCH. They do not apply to MSs on an assigned 
channel (traffic or assigned secondary control). 

23.3.3.1 Beginning of minimum mode 

In the normal mode of operation, the MS shall receive the downlink of the MCCH and shall decode the 
AACH information. In the normal mode of operation, the MCCH is mapped to slot 1 of the main carrier 
frequency. The AACH shall indicate that downlink slot 1 is allocated for common control signalling, with 
the header set to 00 2 or "Field 1 " set to UMc (00001 0 2 ). 

The BS may choose to enter minimum mode by allocating slot 1 of the main carrier for some other 
purpose. The AACH shall indicate that downlink slot 1 is no longer allocated for common control. All MSs 
in idle mode and currently receiving downlink slot 1 shall recognise that the system has entered minimum 
mode. 

Minimum mode during frame 18 shall be assumed by an MS if the AACH indicates that downlink slot 1 in 
frame 17 is allocated for some purpose other than common control signalling. If the AACH cannot be 
decoded in frame 17, then the MS shall assume that the BS is in the mode indicated by the last correctly 
decoded AACH message. The BS shall not enter minimum mode in frame 18 but may only indicate the 
beginning of minimum mode in the AACH of frames 1 to 17. 

NOTE: In order to ensure robust operation, a BS may choose to enter minimum mode several 
frames before frame 18. This would ensure that all MSs have an increased probability 
of correctly decoding the AACH and taking the proper action during frame 18. 

23.3.3.2 MS operation during frames 1-17 

During minimum mode, an MS shall receive slot 1 in frames 2 to 17 so that the BS may send signalling to 
an MS using the stealing channel or fast associated control channel. An MS shall decode the full contents 
of the slot to check whether the information is addressed to that MS. An MS shall decode the AACH in 
downlink slot 1 of frames 1 to 17 so that it can detect the end of minimum mode. If the end of minimum 
mode is detected, the MS shall also decode the full contents of that slot to check whether the signalling 
message contained is addressed to that MS, except if minimum mode ends in frame 1 in which case the 
BS should not assume that every MS is able to receive the full contents of the slot. An MS assigned to slot 
1 during frame 18 in minimum mode shall decode the full contents of slot 1 in frame 1. All other MSs need 
only decode the AACH during slot 1 in frame 1 . 

The BS should not assume that every MS is able to decode slot 1 of frame 1 since an MS assigned to slot 
4 in frame 18 may not be able to decode the following slot in frame 1 . 
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23.3.3.3 MS operation during frame 1 8 

An MS shall receive one of the four downlink slots in frame 18 as allocated to that MS at registration or 
subscription. An MS shall be allocated a minimum mode frame 18 slot at registration or subscription and 
shall receive that assigned downlink slot in frame 18 if the BS has entered minimum mode. The BS, 
therefore, may sub-divide the MS population at registration between the frame 18 slots for minimum mode 
operation according to whatever criteria it chooses to apply, or the sub-division may be applied at 
subscription of the MS population. If an MS has been assigned a minimum mode slot at subscription and 
then also receives a minimum mode slot at registration, the one received at registration shall be used. 

If the MS has not yet registered with the BS in the current LA and has no minimum mode slot from 
subscription then it shall use downlink slot 1 in frame 18 by default. 

NOTE 1 : A BS may choose not to sub-divide the MS population in minimum mode, but instead 
may assign downlink slot 1 as the minimum mode frame 18 slot for all MSs. 

Frame 18 slots shall be shared between idle MSs for common control channel signalling and MSs on 
assigned channels which use frame 18 for associated control signalling. The BS may send downlink 
signalling messages on a downlink slot intended either for an idle MS receiving that slot or for an MS on 
the assigned channel using that slot for associated signalling. The BS shall indicate the destination for 
signalling messages with an address in the MAC header. 

NOTE 2: When an MS obeys a channel allocation command for an assigned channel, it may be 
permitted to continue to use the MCCH if it is capable of doing so (see 
subclause 23.5.4). If the BS is in minimum mode, and if the assigned channel happens 
to correspond to the MS's minimum mode frame 18 slot, then there is a possible 
ambiguity of usage of the downlink slot in frame 18. If this occurs then the MS should 
not attempt concurrent random access on both the MCCH in minimum mode and the 
assigned channel. Also the BS should avoid sending ambiguous fragmented signalling 
in frame 18 or setting up advanced links for that MS on both the MCCH and the 
assigned channel. 

Frame 18 downlink slots shall also be used for broadcast control signalling. The normal mapping of frame 
18 downlink slots for BNCH and BSCH as specified in clause 9 shall apply. 

23.3.3.4 MS operation in energy economy mode 

During minimum mode, an MS in energy economy mode shall not modify its monitoring behaviour. An MS 
waking up to find that the system is in minimum mode shall not modify its monitoring behaviour. The BS 
may page an MS in energy economy mode even during minimum mode by using the STCH or FACCH. 

23.3.3.5 End of minimum mode 

During minimum mode, an MS shall continue to receive the AACH on downlink slot 1 of frames 1 to 17. If 
the AACH indicates that slot 1 is assigned for common control purposes once again, the MS shall 
recognise that the BS is no longer in minimum mode and that normal mode operation has resumed. 

23.3.3.6 Restrictions on usage of minimum mode 

The minimum mode procedures are not applicable for a BS that uses MCCH sharing. 

The minimum mode procedures may apply for a BS that uses main carrier sharing. However, in this case, 
the MS shall always use downlink slot 1 in frame 18 as its minimum mode frame 18 slot, irrespective of 
any value received at subscription or registration. 

The minimum mode procedures apply only to those MSs that are in common control mode and monitoring 
the MCCH. They do not apply to MSs on an assigned channel. Also, they do not apply to an MS that is 
receiving a common SCCH. If the AACH information indicates that the downlink slot is not being used for 
common control purposes, the MS should remain on its common SCCH unless the "number of common 
secondary control channels in use" field changes in the SYSINFO PDU (BNCH). 
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It is optional for an MS to be capable of performing the minimum mode procedures, if the BS enters 
minimum mode, and the MS is not capable of performing the minimum mode procedures, then that MS 
will not receive service during minimum mode. The MS shall not attempt random access and need not 
decode slot 1 for signalling messages. The MS shall at least be able to recognise the beginning and end 
of minimum mode. 

23.3.4 Independent allocation of uplink and downlink 

A BS may allocate uplink and downlink channels for different purposes. This can apply to channels which 
are assigned for use as a traffic channel or control channel. For example, a traffic channel may be 
allocated in the downlink direction when there are only receiving mobiles for that cell and the 
corresponding uplink channel may be allocated for a call which only requires an uplink channel. Some 
examples are listed below: 

a) circuit mode call X on downlink channel; 
circuit mode call Y on uplink channel; 

b) circuit mode call on downlink channel; 
assigned SCCH on uplink channel; 

c) assigned SCCH on downlink channel; 
circuit mode call on uplink channel; 

d) common control on downlink MCCH (slot 1 ); 

uplink slot 1 of main carrier allocated for a circuit mode call; 

e) downlink slot 1 of main carrier allocated for a circuit mode call; 
uplink slot 1 of main carrier available for common control. 

The allocation of uplink and downlink slots is indicated by the contents of the AACH which is broadcast by 
the BS on every downlink slot. All of the above examples can be accommodated with the available 
combinations of the header in the access assignment PDU (see clause 21 for more details). Also, when a 
channel is allocated, the "up/downlink assigned" element in the channel allocation shall inform the MS of 
any restrictions. 

However, for the application of the general procedures for transmission and reception of signalling 
messages, each control channel (ACCH or SCCH) shall be assumed to occupy any control slots on both 
the uplink and downlink directions, as indicated by the "timeslot assigned" element in the channel 
allocation. 

Therefore, for example, in case a), any ACCH in each direction shall be shared by the two unidirectional 
circuit mode calls. Similarly, in cases b) and c), the ACCH and SCCH shall be shared. In cases d) and e), 
the MSs in the circuit mode call shall share the common control channel. 

NOTE: In case a), the two calls X and Y generally involve different MSs. However, it is 
possible that they may be concurrent calls involving the same MS. 

23.3.5 Usage of a multi-slot channel 

A "channel" or "MAC channel", as used in the MAC protocol, means a common control channel or 
assigned channel. A common control channel comprises one timeslot per TDMA frame so it equates with 
a physical channel (see subclause 9.4.1). An assigned channel may comprise more than one timeslot per 
TDMA frame. It then corresponds to a combination of up to four physical channels, as indicated by the 
"timeslot assigned" element in the MAC-RESOURCE PDU that sent the MS to the channel. 

For the purposes of the procedures for transmission and reception of signalling messages on an assigned 
SCCH or an ACCH, all the slots comprising a multi-slot channel are equivalent. Downlink signalling 
messages (including continuation fragments and final fragments) may be sent on any downlink slot 
appropriate to that channel. Also, when the MS is counting slots on the channel (e.g. for the granting delay 
or for a reserved access allocation), all the slots appropriate to that channel shall be counted continuously. 
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This contrasts with the method for a multi-slot circuit mode data service with interleaving depth N = 4 or 8. 
In this case, when the assigned channel is in traffic mode, multiple single-slot data TCHs (TCH/2,4 or 
TCH/4,8) shall be operated in parallel in order to obtain the multi-slot TCH transmission. The N-slot 
interleaving shall be performed within each single-slot TCH, such that interleaved blocks are separated by 
three timeslots. 

NOTE: The use of multiple single-slot data TCHs for the interleaving ensures that the 
performance of multi-slot circuit mode data is the same as that for single-slot circuit 
mode data with the same interleaving depth. This method applies only when the 
assigned channel is in traffic mode. When the channel is not being used for TCH then 
the channel reverts to FACCH and the normal signalling methods apply. 

23.4 General MAC procedures 

23.4.1 PDU header analysis for signalling messages 

23.4.1.1 MAC PDU types 

The header of each MAC PDU enables the receiving MAC to interpret its contents correctly (see clause 21 
for a full description of the PDUs). 

23.4.1 .2 Addressing at the TM A-SAP 

The TMA-SAP MAC headers generally contain an "Address" element and an element specifying the type 
of address. This layer 2 address is the source address for an uplink PDU, or the destination address for a 
downlink PDU. 

Another address (when needed) may be contained within the layer 3 part of the message e.g. the called 
address for an uplink PDU, or the calling address for a downlink PDU. The infrastructure makes the 
required conversion between these different PDUs as appropriate. 

The usage of TETRA addresses and identities is described in ETS 300 392-1 [11], clause 7. 

The address in the MAC header shall be a Short Subscriber Identity (SSI/USSI), a Short Management 
Identity (SMI) or an event label. An SSI/USSI is a 24-bit address specific to a particular TETRA network 
and is part of the complete TETRA Subscriber Identity (TSI). The 24-bit SMI is part of the TETRA 
Management Identity (TMI). An event label is a 10-bit MAC address that may be used to replace an SSI or 
SMI. 

The procedures in this subclause apply to the requirements for a single TSI family. If an MS contains more 
than one TSI family (see ETS 300 392-1 [11], clause 7), then each family shall meet the MAC protocol 
requirements independently of other families. 

23.4.1.2.1 Downlink message 

When the BS transmits a downlink MAC-RESOURCE PDU, it shall use one of the following addresses as 
appropriate as the destination address: 

an Individual Short Subscriber Identity (ISSI); 

an Alias Short Subscriber Identity (ASSI); 

an Un-exchanged Short Subscriber Identity (USSI), used only until a migrating MS has been 
assigned a valid address on this network; 

a Group Short Subscriber Identity (GSSI); 

a Short Management Identity (SMI); 

a valid event label (see subclause 23.4.1 .2.3). 
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The "address type" element in the MAC header shall indicate whether the address is an SSI 
(ISSI/ASSI/GSSI), event label, USSI or SMI; and may be used to assign an event label (or a usage 
marker). 

The receiving MS-MAC shall use the contents of the PDU only if it recognises the address as one of its 
own addresses or event labels. The one exception is that the MS-MAC shall process the MAC header in 
ail received PDUs sufficiently to deduce the length of the PDU, in order to perform dissociation of multiple 
PDUs sent within a MAC block. 

If the MS-MAC receives a PDU with one of its addresses or event labels, it shall pass the TM-SDU to the 
LLC using the TMA-UNITDATA indication primitive. It shall indicate the received address and address 
type, unless the received address is an event label in which case the MS-MAC shall translate the event 
label into the corresponding SSI or SMI before passing the information to the LLC. 

NOTE 1 : The other downlink TMA-SAP PDUs are used for continuations and end of a 
fragmented TM-SDU, and do not contain addressing information. 

NOTE 2: There is no distinction between an ISSI, ASSI or GSSI in the PDU. There is no 
distinction between an ISSI and an ASSI in the MAC. However, it is assumed that the 
MS-MAC knows which of its addresses are group addresses. The MS-MAC also 
knows which of its addresses is the SMI, and it knows whether an address is an USSI. 

NOTE 3: The predefined broadcast group address ("all ones" address), as described in 
ETS 300 392-1 [11], clause 7, defines a group to which all MSs belong. For example, it 
may be used as the destination address for CMCE or SCLNP calls, or it may be used 
by the BS for sending broadcast signalling messages using the services provided at 
the TLA- and TMA-SAP. 

NOTE 4: After an ASSI has been allocated to the MS, the ISSI remains available and may still 
be used by the BS if required. The MS therefore continues to recognise its ISSI on the 
downlink. This applies only on a home network, and not in the case of migration when 
the MS does not have a valid ISSI for the network. 



23.4.1 .2.2 Uplink message 

When the MS-MAC is required to send a C-plane message, it receives a TMA-UNITDATA request 
primitive from the LLC. This primitive shall contain the appropriate layer 2 address (the main address) and 
the address type. 

The main address in the request primitive shall be one of the following: 



the ISSI or ASSI for the network; 

an USSI, used only by a migrating MS for the initial registration request; 



a GSSI; 



the SMI for the MS. 

When the MS-MAC forms a MAC-ACCESS or MAC-DATA PDU, it shall use the main address from the 
TMA-UNITDATA request primitive in the PDU "Address" element, unless an event label has been 
assigned for this address (see subclause 23.4.1.2.3) in which case it may use the event label when 
appropriate. The "Address type" in the MAC header shall indicate whether the address element contains 
an SSI (ISSI/ASSI/GSSI), event label, USSI or SMI. 

NOTE 1 : The other uplink TMA-SAP PDUs are used for continuations and end of a fragmented 
TM-SDU, and do not contain addressing information. 

NOTE 2: A group address in the MAC header is only ever used on the uplink for the layer 2 
group presence indication. 

NOTE 3: After an ASSI has been allocated to the MS, and while it is still valid, that ASSI should 
be used in uplink messages in preference to the ISSI. 
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An "event label" is a temporary shortened form of address which replaces a specified SSI (ISSI, ASSI or 
GSSI) or a specified SMI in the MAC PDUs, and is visible only at the MAC layer, it is valid only on one 
control channel. Its usage is illustrated in figure 142. 

Event label 0 (all zeros) may be used for withdrawing an event label assignment. It is not valid for normal 
use. 

When the BS wishes to assign an event label, it shall use the MAC-RESOURCE PDU, which shall contain 
both the SSI (respectively SMI) and the assigned event label. If the BS includes a "channel allocation" 
element in the MAC-RESOURCE PDU, then the event label shall apply on the allocated channel; 
otherwise the event label shall apply on the current control channel. 

NOTE 1: For a channel allocation with "allocation type" = 11 2 (Replace + CSS channel), the 
event label applies only on the assigned channel, not on the CSS channel (see 
subclause 23.5.4 for a description of the allocation types). 

The MS-MAC may then use the event label (if non-zero) instead of the corresponding SSI (respectively 
SMI) as the source address in uplink PDUs sent on this control channel, see figure 142. While the event 
label is valid, it may be used for both basic link and advanced link messages, and for random access, 
reserved access and STCH. 

The BS may use the event label as the destination address in downlink PDUs (though the corresponding 
SSI or SMI may still be used). If the MS-MAC receives a downlink PDU containing a valid event label then 
it shall process the information contained in that PDU. The MS-MAC shall translate the event label into the 
corresponding SSI (respectively SMI) before passing the TM-SDU to the LLC. 

The event label has a limited lifetime. The MS-MAC shall consider that an assigned event label is no 
longer valid in the following cases: 

1) a time T.201 has elapsed since the MS last received a downlink PDU containing that event label. 
Then the MS-MAC shall revert to using the SSI (respectively SMI); 

2) the MS receives another event label assignment on this control channel, for the same SSI 
(respectively SMI). Then, if the received event label is non-zero, the MS-MAC shall accept that new 
event label; if the received event label = 0, the MS-MAC shall revert to using the SSI (respectively 
SMI); 

3) the MS moves to another channel. Then the MS-MAC shall revert to using the SSI (respectively 
SMI), unless a new event label was assigned with the channel allocation. 

The BS is responsible for ensuring that it does not re-use an event label for another MS until the valid 
lifetime has expired. 

NOTE 2: Event label assignment is intended primarily for when an advanced link has been 
set-up for the appropriate address. However, its use is not precluded when there is 
only a basic link. 
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The SMI is an address specific to a particular TETRA network and is part of the complete TMI. The 
management identity can be used to address a particular piece of equipment independently from the 
subscriber identity. 

NOTE: The subscriber identities may be transferable, and may be removed from the 
equipment by the user. 

The SMI enables management functions to be performed over the air interface. Alternatively, if the 
infrastructure knows the correspondence between the equipment and the SSI, it may use the SSI for the 
management functions, since the management messages can be recognised by the MLE (see clause 18). 

The SMI may be numerically equal to an SSI attached either to that MS or to another MS. The SSI and 
SMI remain distinct because they can be distinguished by the address type in the MAC PDUs. 



23.4.1.2.5 Usage of USSI 

An USSI is the SSI of an MS from a foreign ITSI. It shall only be used in case of migration, when the MS 
does not have a valid ISSI or ASSI for the network, and shall only be used for the registration procedure. 
The USSI is equal to the ISSI used by the MS in its home network. 

When migrating into a network, the first message sent by an MS shall be a registration request, with the 
USSI as the layer 2 source address. The home MCC and MNC are included within the layer 3 part of the 
message. 

The USSI is then used on the downlink, in the BS response, as the layer 2 destination address. Also, if the 
layer 3 reply from the BS is not sent with the MAC response, the USSI will be used again as the layer 2 
address when the BS sends the layer 3 reply. 



Page 452 

ETS 300 392-2: March 1996 

The layer 3 reply to the registration request carries an ASSI for the visiting MS; that new SSI shall then be 
used by the MS inside the visited network. The allocated ASSI may be (by chance) equal to the USSI, but 
usually is not. 

Sometimes, the USSI may be numerically equal to an SSI or SMI already in use by another MS on the 
visited network. The signalling messages remain distinct because they can be distinguished by the 
address type in the MAC PDUs. 

Sometimes, the USSI may be numerically equal to the USSI of another migrating MS that is trying to 
register at the same time. In this case, the downlink signalling messages are not distinct at layer 2. 
However, the layer 3 reply from the BS contains the MS's home MCC and MNC, and the MM in the MS 
will discard a received reply if it has incorrect MCC or MNC (see clause 16). 

After the MS has received an ASSI, the USSI becomes invalid for use on this network, the MS shall not 
use the USSI in uplink messages and shall not recognise the USSI in downlink messages. 

23.4.1 .3 Addressing at the TMB-SAP 

The characteristic of this SAP is that the broadcast information (system information) is implicitly 
addressed to every MS and, in order to keep the overhead as low as possible, does not contain an 
address field. The MAC PDU type under the TMB-SAP is distinct from those used under the TMA-SAP 
(see clause 21). The LLC shall be transparent for system broadcasts. No address is reported by the MAC 
to the MLE. 

NOTE: Broadcast messages under the TMB-SAP comprise only the SYNC PDU (i.e. content 
of BSCH), SYSINFO PDU (i.e. content of BNCH) and ACCESS-DEFINE PDU. They 
should not be confused with signalling messages addressed to a group of MSs in the 
downlink using a specific group address at the TLA-SAP and TMA-SAP. Broadcast to 
all MSs in a cell or wider area may use the predefined broadcast group address ("all 
ones" address) and the services provided at the TLA- and TMA-SAP (see 
subclause 23.4.1.2.1). 

23.4.1 .4 Addressing at the TMD-SAP 

There is no addressing at the TMD-SAP. There may be multiple endpoints in the TMD-SAP which shall be 
associated with the corresponding CC instance and address used in the set-up phase in the user 
application. 

If the MAC steals from the circuit mode capacity to send C-plane signalling, it shall use TMA-SAP PDUs 
and addressing. 

23.4.2 PDU composition for signalling messages 

This subclause describes the mechanisms whereby PDUs may be transmitted in the MAC blocks in full or 
half-slot SCH. Three general mechanisms are provided: 

a) fragmentation: 

this is the subdivision procedure that shall be used by an MS-MAC or BS in the case that a 
TM-SDU received from the LLC exceeds the available capacity in a MAC block. The 
transmission of the TM-SDU is then subdivided between two or more MAC blocks; 

b) fill bit addition: 

the length of a MAC PDU is generally represented as a number of octets. "Fill bits" shall be 
used when the PDU does not fully occupy the indicated PDU length. They are used to make 
up the difference between the actual PDU content and the indicated length, and they also 
show the exact end of the TM-SDU; 

c) association: 

this is the procedure that may be used by an MS or BS for sending two or more PDUs within 
a single MAC block. 
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The reverse procedures (called reconstruction, fill bit deletion and dissociation respectively) are described 
in subclause 23.4.3. 

23.4.2.1 Fragmentation (TMA-SAP only) 

Fragmentation is the procedure that shall be used by an MS-MAC or BS in the case that a TM-SDU 
received from the LLC exceeds the available capacity in the MAC block. The MAC subdivides the 
TM-SDU into a number of fragments, where each fragment is sent within one MAC PDU. The whole 
TM-SDU contains only a single LLC header. This procedure is illustrated in clause 21, figure 99. 
Fragments are not numbered, and so they shall be sent in sequence. If an error occurs during 
transmission then the MAC procedure fails (and the LLC has to request a re-transmission of the whole 
TM-SDU). From the point of view of the higher layers, the process is the same as if the TM-SDU had been 
transmitted in a single MAC block. 

The first fragment of a TM-SDU shall be sent with a full MAC header (MAC-RESOURCE PDU on the 
downlink, MAC-ACCESS or MAC-DATA PDU on the uplink). Whereas continuation fragments 
(MAC-FRAG PDU) and the final fragment (MAC-END or MAC-END-HU PDU) shall be sent with a reduced 
header, (see clause 21). In particular, only the full MAC header contains addressing information. 

Fragmentation applies only to subdivision of the actual TM-SDU. The MAC header cannot be subdivided 
between MAC blocks. 

On the downlink, the BS may temporarily interrupt a fragmented message to send other signalling, 
whereas, on the uplink, the MS-MAC shall not interleave any other signalling with a fragmented TM-SDU. 

NOTE 1 : The fragmentation procedure is intended for use for basic link messages, if a TM-SDU 
exceeds the capacity of the MAC block. It is recommended that the MS/BS does not 
fragment advanced link messages. 

NOTE 2: The fragmentation procedure is not intended for very long messages. It is 
recommended that fragmentation is not used for TL-SDUs exceeding approximately 
133 octets (if using FCS) or 137 octets (if not using FCS) i.e. MAC-ACCESS + four full 
slots. And fragmentation cannot be used for TL-SDUs exceeding 324 octets (if using 
FCS) or 328 octets (if not using FCS). Instead, the MLE should set-up an advanced 
link (or use an existing advanced link). It is recommended that the MLE uses the 
optional FCS if it sends long messages on the basic link (but not when it sends short 
signalling messages). 

NOTE 3: There is no MAC acknowledgement or MAC re-transmission of a fragmented 
TM-SDU. Acknowledgements and re-transmissions are under the control of the LLC. 



23.4.2.1.1 Fragmentation of downlink TM-SDU 

When the BS wishes to send a TM-SDU that does not require fragmentation, it shall send the entire 
TM-SDU within the MAC-RESOURCE PDU. 



When the BS wishes to send a TM-SDU that exceeds the available capacity within a MAC block, it may 
subdivide the TM-SDU into fragments, which shall be sent on this control channel, in the following 
sequence: 

a) the first fragment shall be sent using the MAC-RESOURCE PDU; 

b) any continuation fragments shall be sent using n * MAC-FRAG PDUs (where n > 0); 

c) the final fragment shall be sent using the MAC-END PDU. 

Since the MAC-END PDU header is longer than the MAC-FRAG header, there may be some cases when 
the remainder of the TM-SDU fits within MAC-FRAG but would not fit within MAC-END. In these cases, 
the BS should send the remaining data within MAC-FRAG (with fill bits if necessary) and then send an 
empty MAC-END PDU to complete the message. 
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When the BS has sent one or more fragments of a fragmented message, it may temporarily interrupt the 
transmission if necessary to send a TMB-SAP broadcast message or a non-fragmented TMA-SAP 
message (but not a fragmented message). However, the MS-MAC receiving the fragmented message will 
discard a partially received TM-SDU if it does not receive a fragment in at least every second slot on this 
downlink control channel (see reconstruction by MS given in subclause 23.4.3.1 .1). 

The MAC PDU structure allows only one first fragment or continuation fragment to be sent per MAC block. 
This shall be sent as the last PDU in the MAC block. In the MAC-RESOURCE PDU that contains the first 
fragment, the "Length indication" element shall be set to 1 1 1 1 1 12. 

The BS may abort a fragmented transmission at any time before transmission of MAC-END by sending no 
more fragments of the message. 

If the BS wishes to send slot granting information with a fragmented message, the grant may be included 
in either the MAC-RESOURCE or the MAC-END PDU. 

If the BS wishes to send channel allocation information with a fragmented message, then this information 
shall be included within the MAC-END PDU and shall not be included within the MAC-RESOURCE PDU. 

NOTE: For a multi-slot control channel, all the downlink slots comprising that control channel 
are equivalent. In particular, the continuation and final fragments may be transmitted 
on any downlink slot appropriate to that channel (as indicated by the "Timeslot 
Assigned" element from the MAC-RESOURCE PDU that allocated the channel), they 
are not restricted to the same timeslot number as the first fragment. 

23.4.2.1 .2 Fragmentation of uplink TM-SDU 

When the MS-MAC wishes to send a TM-SDU that does not require fragmentation, it shall send the entire 
TM-SDU within the MAC-ACCESS PDU or the MAC-DATA PDU. MAC-ACCESS applies if the MS-MAC is 
using random access or a subslot granted by the BS. MAC-DATA applies if the MS-MAC is using a full 
slot granted by the BS. After transmission in a granted subslot or slot, the MS-MAC shall inform the LLC 
that the TM-SDU has been sent (using the TMA-REPORT indication primitive). 

The MS-MAC may perform fragmentation of a TM-SDU using any of the following transmission forms: 

i) MAC-ACCESS + MAC-END-HU; 

ii) MAC-ACCESS + n * MAC-FRAG + MAC-END 0 < n < 9; 

iii) MAC-DATA + MAC-END-HU; 

iv) MAC-DATA + n * MAC-FRAG + MAC-END 0 < n < 9; 

Form i) or ii) shall apply if the MS-MAC is using random access to start the process or if the MS-MAC is 
granted a subslot by the BS. Form iii) or iv) shall apply if the transmission starts in a full slot granted by the 
BS. 

When the MS-MAC wishes to send a TM-SDU, it shall first determine whether fragmentation is required 
and, if so, the required capacity to carry the TM-SDU. 

For MAC-ACCESS, fragmentation is required for a TM-SDU exceeding 62 bits. If fragmentation is 
required, the MAC-ACCESS can carry a first fragment of 56 bits of TM-SDU. 

For MAC-DATA, fragmentation is required for a TM-SDU exceeding 231 bits (and the MAC-DATA can 
carry a first fragment of 231 bits of TM-SDU). 

NOTE 1 : The above numbers assume that the first fragment is the only PDU within the MAC 
block. If association has occurred within the subslot or slot, the available size is 
reduced correspondingly. Fragmentation can only be used after association if the 
complete MAC header, plus at least one bit of TM-SDU, can be sent within the MAC 
block. 



Page 455 
ETS 300 392-2: March 1996 

NOTE 2: The above numbers assume the use of an SSI or SMI in the MAC header. If an event 
label is used, then the available sizes are increased by 14 bits. 

If the remainder of the TM-SDU does not exceed 85 bits, then the transmission can be completed with a 
single subslot (MAC-END-HU PDU). 

Otherwise, the MS-MAC shall determine the required number (N=n+1) of full slots to send the remainder 
(R bits) of the TM-SDU: 

ifR<258, N = 1; 

if R > 258, N = 2 + (R-259) DIV 264; 
where DIV represents integer division, rounded down. 

The MS-MAC shall use the following procedure for sending a fragmented TM-SDU: 

the MS-MAC shall send the first fragment in the MAC-ACCESS or MAC-DATA PDU, setting the "fill 
bit indication" to indicate that no fill bits are present and the optional elements to include the 
"Capacity request" indicating: 

start of fragmentation; 

the reservation requirement for the remainder of the TM-SDU (and for any other messages 
which the MS has ready to send on this control channel); 

if the MS-MAC requested only a subslot then it shall send the final fragment in the first granted 
subslot or full slot on this control channel (using MAC-END-HU or MAC-END respectively). The "fill 
bit indication" shall be used to indicate whether or not fill bits are used within the PDU; 

if the MS-MAC requested one or more full slots then it shall send further fragments in full slots on 
this control channel, using n MAC-FRAG PDUs and then one MAC-END PDU. It shall send 
fragments in any slots already granted, and in slots as they are granted by the BS (in one or more 
slot grants). 

For the first n-1 MAC-FRAG PDUs, the MS-MAC shall include fragments of 264 bits of the TM-SDU 
(with no fill bits). For the last MAC-FRAG, the MS-MAC shall include the next 264 bits of the 
TM-SDU, or the remainder of the TM-SDU if this is less than 264 bits (with the "fill bit indication" 
used to indicate the end of the user data). 

The MS-MAC shall include the remaining part (if any) of the TM-SDU in the MAC-END PDU. The 
"fill bit indication" shall be used to indicate whether or not fill bits are used within the PDU. 

The transmission process described above shall be continued until one of the following occurs: 

a) the MS-MAC sends the MAC-END-HU or MAC-END PDU: 

the MS-MAC shall then inform the LLC that the TM-SDU has been sent by reserved access 
(using the TMA-REPORT indication primitive); 

the remainder (if any) of the MAC block shall be completed either by a Null PDU (plus fill bits) 
or by a MAC-ACCESS or MAC-DATA PDU by association as appropriate; 

if the MS has further signalling to send on this control channel, then the MS-MAC shall 
include the reservation requirement in the MAC-END-HU/MAC-END (or in the last PDU in the 
MAC block if association is performed); 
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b) the MS-MAC does not have any individually granted capacity on this control channel and a time 
T.202 has elapsed since: 

it last transmitted a fragment; or 

it last received a slot granting element on this control channel containing the instruction to 
"Wait for another Slot Grant"; 

whichever is the later; 

the MS-MAC shall then inform the LLC that the transmission has failed (using the TMA- 
REPORT indication primitive), and shall discard the TM-SDU; 

c) the MS-MAC asked for full slot reservation, and it receives a subslot grant: 

the MS-MAC shall then inform the LLC that the transmission has failed (using the TMA- 
REPORT indication primitive), and shall discard the TM-SDU. The MS-MAC may use the 
granted subslot to send another TM-SDU; 

d) the MS-MAC receives a TMA-CANCEL request from the LLC, cancelling transmission of this 
message; 

the MS-MAC shall discard the TM-SDU (reporting to the LLC that the message was not 
completely sent); 

if the MS-MAC is granted any further subslots or slots, it may send another TM-SDU. 
23.4.2.1 .3 Fragmentation in minimum mode 

Fragmentation is possible in minimum mode. However, long delays may be introduced, particularly for 
fragmentation over more than two MAC blocks. Therefore, an MS or BS may choose not to perform 
fragmentation during minimum mode, and the BS may (as always) choose not to grant slots to an MS for 
continuation of a fragmented message. 

a) Downlink TM-SDU 

The general procedure for downlink fragmentation, described in subclause 23.4.2.1.1, applies 
during minimum mode except that, when sending a fragmented message to an MS, the only MAC 
blocks that the BS may use for MAC-FRAG or MAC-END are those in the MS's designated 
minimum mode frame 18 slot. The MS-MAC receiving the fragmented message will discard a 
partially received TM-SDU if it does not receive a fragment in at least every second frame 18. 

NOTE: Not all MSs will receive all AACH blocks, so there is some uncertainly about exactly 
when a particular MS enters and leaves minimum mode. Therefore, if the BS is in 
process of sending a fragmented message when it enters or leaves minimum mode, it 
may prefer to abort the transmission. 

b) Uplink TM-SDU 

During minimum mode, the MS-MAC shall follow the defined minimum mode rules for monitoring 
and decoding the downlink for signalling messages (e.g. for receiving slot grants from the BS). 

The general procedure for uplink fragmentation, described in subclause 23.4.2.1 .2, applies, 
although, since time T.202 is counted in downlink signalling opportunities, in minimum mode the 
absolute time is 18 times its usual value). 
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23.4.2.1 .4 Fragmentation on time-shared control channel 

a) Downlink TM-SDU 

The general procedure for downlink fragmentation, described in subclause 23.4.2.1.1, applies on a 
time-shared MCCH except that, when sending a fragmented message to an MS, the only MAC 
blocks that the BS may use for MAC-FRAG or MAC-END are those in the reserved frames for this 
BS, not the common frames. The MS-MAC receiving the fragmented message will discard a 
partially received TM-SDU if it does not receive a fragment in at least every second reserved frame. 

b) Uplink TM-SDU 

On a time-shared MCCH, the MS-MAC shall follow the defined rules for monitoring and decoding 
the downlink for signalling messages (e.g. for receiving slot grants from the BS). The normal 
procedure for uplink fragmentation, described in subclause 23.4.2.1.2, applies, although, since time 
T.202 is counted in downlink signalling opportunities, on a time-shared control channel the absolute 
time is greater than on a non-time-shared channel. 

23.4.2.1 .5 Fragmentation on stealing channel 

On the stealing channel STCH, fragmentation is only permitted within one slot. Neither the MS nor the BS 
shall attempt to perform fragmentation over more than one stolen slot. 

The procedure for transmission on STCH (including fragmentation) is described in subclause 23.8.4. 

23.4.2.2 Fill bit addition 

Fill bits shall be added when the actual size of the MAC PDU is less than the PDU length indicated in the 
MAC header, or less than the available capacity of the MAC block. Fill bit addition applies only to 
TMA-SAP PDUs. 

If fill bits are added, the MAC shall set the "Fill bit indication" in the MAC header to 1. In order to add fill 
bits within a PDU, the MAC shall: 

add a bit "1 u immediately following the last bit of the TM-SDU data; 

complete as appropriate with bits set to "0"; 

if a length indication is included in the MAC header, then complete with 0 to 6 bits set to "0" 
until the size of the PDU corresponds to the indicated length or the available capacity of the 
MAC block (if that is less than the indicated length); 

if a length indication is not included in the MAC header (or if the length indication is set to 
1 1 1 1 10 2 ), then complete with the required number of zeros to fill the MAC block. 

Fill bits inserted after a Null PDU to complete the MAC block shall be set to "0", except for the first bit after 
the Null PDU which shall be set to M". 

When there is not enough space to insert a Null PDU in the remainder of a MAC block, fill bits shall be 
used so that the first bit after the user data shall be set to "1" and the following bits shall be set to "O". 

The procedure for fill bit addition is valid for both MS and BS. 

23.4.2.3 PDU association 

PDU association may be used when several small PDUs can be fitted into a single MAC block for transfer 
across the air interface. The PDUs are independent. And the BS may associate PDUs addressed to 
different MSs within one MAC block. The association procedure is illustrated in clause 21, figure 97. 
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Each PDU shall contain its own header, and each TMA-SAP PDU, except possibly the last in the MAC 
block, shall indicate the length of the PDU as a number of octets. The header of the next PDU shall 
immediately follow the end of the current PDU. Within a PDU, fill bits shall be inserted as required. If there 
are no more PDUs to follow, a special message (the Null PDU) may be used if it fits within the remaining 
space in the MAC block. If there are unused bits, they shall follow the rules for fill bit addition. 

This procedure is valid for both MS and BS. 

In order to associate, the MAC shall: 

a) prepare a PDU: 

for a TMA-SAP PDU, the MAC shall place the relevant header in front of the TM-SDU, 
including the PDU length in octets (except in the cases noted below); the number of octets is 
rounded up to the next integer value of (PDU size in bits)/8; 

for a TMB-SAP PDU, the size of the PDU is implicit from the MAC header; 

b) if the PDU does not completely fill the MAC block then: 

if the size of the remainder of the MAC block < appropriate Null PDU size (see below) then 
the MAC shall fill the remainder with fill bits; or 

if the size of the remainder of the MAC block > appropriate Null PDU size (see below) then 
the MAC shall either: 

repeat step a) with another PDU; or 

use the Null PDU and complete the remainder (if any) with fill bits. 

For the downlink, the Null PDU size to be used for the comparison in b) shall be 16 bits. For the uplink, the 
comparison in b) shall be performed using the Null PDU size that corresponds to an address length of 
24 bits. This is 36 bits in a subslot, or 37 bits in a full slot or on STCH. This rule shall apply even if the MS 
has been assigned an event label. 

Association shall not be performed if the remainder of the MAC block is less than the size of the 
appropriate Null PDU, even if the MAC has a PDU to send that is shorter than the Null PDU. 

NOTE 1: The "Length indication" element in the MAC header refers to the size of the complete 
MAC PDU in octets (rounded up), not to the length of the TM-SDU. The length of the 
TM-SDU is then known, since the TM-SDU follows immediately after the MAC header. 

The required PDU length in octets is: 



1 + ( (BITS-1) DIV 8 ), where BITS is the PDU size in bits. 

There will be some cases when the PDU only just fits within the MAC block so that, 
after rounding up, the "length indication" may indicate a value which exceeds the 
available capacity of the MAC block. 

NOTE 2: In this ETS, the only TMB-SAP PDU for which association may apply is 
ACCESS-DEFINE. 

When a BS performs fragmentation, it shall send the first fragment and continuation fragments as the last 
PDU in a MAC block, or when an MS has further signalling to send, it shall include the reservation 
requirement in the MAC header of the last (non-Null) PDU in a MAC block. In both these cases, the PDU 
length cannot be indicated in the MAC header. Also, when an MS-MAC does not require to perform 
association within an uplink subslot, it should not include the "length indication" element in the 
MAC-ACCESS PDU except when it needs to send the Null PDU in a subslot. 

In all three cases, the PDU shall be deemed to fill the remainder of the MAC block, and the length of the 
TM-SDU, or TM-SDU fragment, shall be indicated by use of the "Fill bit indication" and any fill bits. 



Page 459 

ETS 300 392-2: March 1996 

23.4.3 PDU decomposition for signalling messages 
23.4.3.1 Re-construction (TMA-SAP only) 

This procedure is the opposite to fragmentation which is performed by the sender as described in 
subclause 23.4.2.1. 

23.4.3.1 .1 Reconstruction of downlink TM-SDU 

The MS-MAC shall receive the downlink slots appropriate to the relevant control channel within the 
constraints of the energy economy regime and the cell re-selection procedures. 

On receipt of a MAC-RESOURCE PDU containing one of its addresses, the MS-MAC shall perform the 
following actions relating to the TM-SDU. Other actions may be performed relating to other elements in 
the MAC header. 

a) If the MAC-RESOURCE PDU contains "Length indication" * 111111 2 , indicating no fragmentation, 
then the MS-MAC shall deliver the TM-SDU (if any) to the LLC using the TMA-UNITDATA indication 
primitive. 

b) If the MAC-RESOURCE PDU contains "Length indication" = 111111 2 , indicating the start of 
fragmentation, then the MS-MAC shall store the TM-SDU fragment. 

NOTE 1: The length of the first fragment is indicated only by the "fill bit indication" and any fill 
bits. 

The MS-MAC shall then receive all the downlink slots on this control channel, looking for 
continuation fragments or for the end of the fragmented data i.e. MAC-FRAG or MAC-END PDU 
respectively. 

On receipt of a MAC-FRAG PDU, the MS-MAC shall append the TM-SDU fragment to the already 
received fragment(s). The length of a continuation fragment is indicated only by the "fill bit 
indication" and any fill bits. The MS-MAC shall then continue to monitor the control channel for 
further MAC-FRAG PDUs or for the MAC-END PDU. 

On receipt of a MAC-END PDU, the MS-MAC shall append the TM-SDU fragment to the already 
received fragment(s). The length of the final fragment is indicated by the combination of the "Length 
indication", the "fill bit indication" and any fill bits. The MS-MAC shall then deliver the reconstructed 
TM-SDU to the LLC using the TMA-UNITDATA indication primitive. 

NOTE 2: Occasionally the MAC-END PDU will contain no user data, in which case the already 
assembled fragments comprise the complete TM-SDU. On receipt of MAC-END, the 
MS-MAC delivers the TM-SDU to the LLC. 

The MS-MAC shall continue this process until it receives the MAC-END PDU, or until one of the 
following occurs: 

i) it receives any MAC-RESOURCE PDU containing "Length indication" = 111111 2 (for any 
address, not only one of its own addresses); 

ii) it fails to decode a SCH/HD or SCH/F MAC block on this control channel; 

iii) it does not receive a fragment of its TM-SDU in two consecutive slots on this control channel. 

In all three cases, the MS-MAC shall discard the partially reconstructed TM-SDU. In case i), if the 
MAC-RESOURCE PDU contains one of its own addresses, the MS-MAC shall then continue to 
process that new PDU. 

The MS shall provide adequate buffering to store a fragmented TM-SDU which may be up to N.202 bits in 
length. The MS-MAC does not deliver any part of the TM-SDU to the LLC until the complete TM-SDU has 
been received. 
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23.4.3.1 .2 Reconstruction of uplink TM-SDU 

On receipt of a MAC-ACCESS or MAC-DATA PDU, the BS shall perform the following actions relating to 
the TM-SDU. 

If the received PDU does not indicate start of fragmentation then the BS shall assume that the received 
TM-SDU is complete. 

If the received PDU indicates start of fragmentation, and if the BS decides to grant capacity for the 
fragmented message, then the BS shall store the TM-SDU fragment. It shall also monitor any subslot or 
slots granted to the MS on this control channel (either granted already or granted in subsequent MAC- 
RESOURCE or MAC-END PDUs), looking for further fragments of the TM-SDU. 

a) If the MS requested a single subslot, and the BS grants a subslot for a final fragment, then the BS 
shall inspect the first PDU in that subslot. 

If it receives the MAC-END-HU PDU, the BS shall append the TM-SDU fragment to the first 
fragment, and shall assume that the received TM-SDU is complete. 

If it receives the MAC-ACCESS PDU, the BS shall discard the old fragment and shall continue to 
process the new PDU. 

If it fails to decode the uplink subslot, the BS shall discard the old fragment. 

b) If the BS grants full slots to the MS, then it shall monitor those granted slots for the MAC-FRAG or 
MAC-END PDU. 

On receipt of a MAC-FRAG PDU, the BS shall append the TM-SDU fragment to the already 
received fragment(s). It shall then continue to monitor the granted slots for further MAC-FRAG 
PDUs or for the MAC-END PDU. 

On receipt of a MAC-END PDU, the BS shall append the TM-SDU fragment to the already received 
fragment(s), and shall assume that the received TM-SDU is complete. 

NOTE 1: Occasionally the MAC-END PDU will contain no user data, in which case the already 
assembled fragments comprise the complete TM-SDU. 

The BS may continue this process (granting more slots if appropriate) until it receives the 
MAC-END PDU, or until one of the following occurs: 

i) it receives a MAC-DATA PDU in one of the granted slots; 

ii) it fails to decode a MAC block in one of the granted slots; 

iii) it has not granted slots to the MS nor sent the instruction to "Wait for another Slot Grant", and 
a time T.202 has elapsed since the last slot granted to the MS on this control channel (see 
subclause 23.4.2.1.2). 

In all three cases, the BS shall discard the partially reconstructed TM-SDU. In case i), the BS shall 
continue to process the new PDU. In case ii), the BS shall discard any MAC-FRAG or MAC-END 
PDUs received in any further slots granted to this MS (until receipt of the next MAC-ACCESS or 
MAC-DATA PDU from this MS). 

If, at any time, the BS receives a MAC-FRAG, MAC-END or MAC-END-HU PDU in a granted slot or 
subslot, without a corresponding start of fragmentation from this MS (on this control channel), the BS shall 
discard the PDU. 



NOTE 2: After receiving a fragmented TM-SDU containing a BL-DATA or BL-ADATA message, 
the BS may choose to send the LLC acknowledgement more than once (for reliability). 
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23.4.3.1 .3 Reconstruction in minimum mode 

a) Downlink TM-SDU 

During minimum mode, the MS-MAC shall follow the defined minimum mode rules for receiving and 
decoding the downlink for signalling messages in frames 1-17 and in frame 18. 

The normal procedure for reconstruction of a downlink TM-SDU, described in subclause 23.4.3.1.1, 
generally applies except that, after the MS-MAC receives a MAC-RESOURCE PDU addressed to 
itself and containing a start of fragmentation, the procedure b) for looking for continuation fragments 
(MAC-FRAG) or for the end of the fragmented data (MAC-END) shall apply only to the MS's 
designated minimum mode frame 18 slot. 

Also, the normal criteria ii) and iii) for discarding a partially reconstructed TM-SDU shall be replaced 
by the following: 

i) it fails to decode a SCH/HD or SCH/F MAC block in its designated minimum mode frame 18 
slot; 

ii) it does not receive a fragment of its TM-SDU in its designated minimum mode slot in two 
consecutive frame 18s. 

On leaving minimum mode, the MS-MAC shall return to the normal method of reconstruction (i.e. 
looking for fragments in all downlink slots on the MCCH). 

NOTE 1 : The above minimum mode procedure applies only to those MSs that are in common 
control mode and monitoring the MCCH. It does not apply to MSs on an assigned 
channel. 

NOTE 2: While receiving a fragmented message during minimum mode, the MS-MAC is still 
required to monitor slot 1 of frames 2-17, e.g. it may be sent a non-fragmented 
message. 

b) Uplink TM-SDU 

The normal procedure for reconstruction of an uplink TM-SDU, described in subclause 23.4.3.1.2, 
applies during minimum mode. 

23.4.3.1 .4 Reconstruction on time-shared control channel 

a) Downlink TM-SDU 

On a time-shared MCCH, the MS-MAC shall follow the defined rules for receiving and decoding the 
downlink for signalling messages. 

The normal procedure for reconstruction of a downlink TM-SDU, described in subclause 23.4.3.1.1, 
generally applies except that, after the MS-MAC receives a MAC-RESOURCE PDU addressed to 
itself and containing a start of fragmentation, the procedure b) for looking for continuation fragments 
(MAC-FRAG) or for the end of the fragmented data (MAC-END) shall apply only to slot 1 of the 
reserved frames for this BS, not to the common frames. 

Also, the normal criteria ii) and iii) for discarding a partially reconstructed TM-SDU shall be replaced 
by the following: 

i) it fails to decode a SCH/HD or SCH/F MAC block in slot 1 of one of the reserved frames for 
this BS; 

ii) it does not receive a fragment of its TM-SDU in slot 1 of two consecutive reserved frames for 
this BS. 

NOTE: While receiving a fragmented message, the MS-MAC is still required to monitor slot 1 
of the common frames, e.g. it may be sent a non-fragmented message. 
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For a time-shared common SCCH, "slot 1" in the above shall be replaced by the appropriate slot 
number on the main carrier. 

b) Uplink TM-SDU 

The normal procedure for reconstruction of an uplink TM-SDU applies. 

23.4.3.1 .5 Reconstruction on stealing channel 

On the stealing channel STCH, fragmentation is only permitted within one timeslot. The procedure for 
reception of STCH (including reconstruction within the two half slots of one stolen timeslot) is described in 
subclause 23.8.4. 

23.4.3.2 Fill bit deletion 

On receipt of a TMA-SAP PDU, the MAC shall check whether fill bits are present ("fill bit indication" set to 
1 in the PDU header). If fill bits are present, the MAC shall: 

inspect the last bit of the PDU; 

if the last bit is "1 \ remove this bit; then the rest of the data is the true PDU content; 

if the last bit is "0", remove this bit and all preceding zeros until a bit "1" is found; remove this bit "1"; 
then the rest of the data is the true PDU content. 

The maximum number of fill bits to remove is normally 7 bits if a specific length indication is given in the 
MAC header. It may be a larger number if there is no length indication or if the length indication is set to 
111110 2 . 

Fill bits used for completing a MAC block after the Null PDU, or if there is not enough space for a Null 
PDU, shall be discarded. 

The procedure for fill bit deletion is valid for both MS and BS. 

23.4.3.3 PDU disassociation 

PDU disassociation shall be used when several small PDUs have been fitted into a single MAC block by 
the association procedure. 

Each TMA-SAP PDU (except possibly the last in the MAC block) indicates the length of the PDU, as a 
number of octets. The MAC header of the next PDU immediately follows the end of the current PDU as 
indicated by the "length indication" element. So separation of PDUs from each other relies on the "length 
indication" contained in the first MAC header, then the second, and so on. The Null PDU indicates that 
there is no more useful data in this MAC block; after receipt of the Null PDU, the MAC shall not look for 
further information in the block. If the remaining size in the MAC block is less than the length of the Null 
PDU, the MAC shall discard the remaining bits. 

This procedure is valid for both MS and BS. 

In order to disassociate, the MAC shall: 

decode the first MAC header and extract the PDU length indication (if included); if there is no length 
indication for a TMA-SAP PDU, the PDU size shall be deemed to be the remainder of the MAC 
block; for a TMB-SAP PDU, the exact size of the PDU is implicit from the MAC header; 

remove any fill bits contained in the PDU, if indicated by the "fill bit indication"; 

repeat the above steps until a Null PDU is found or the remaining space in the block is less than the 
size of the appropriate Null PDU. 

Each separate PDU shall then be further processed by the MAC. 
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There will be some cases when the "Length indication" will indicate a value which exceeds the available 
capacity of the MAC block. The recipient MAC shall regard the length of the PDU as either the available 
capacity of the MAC block or the indicated length, whichever is the lesser. In either case, fill bits shall be 
removed if the fill bit indication is set to "1 M . 

NOTE: The size of the appropriate Null PDU (as used above) is 16 bits for the downlink, 
36 bits for an uplink subslot, 37 bits for an uplink full slot or uplink STCH. 

23.4.3.4 PDU error detection 

The purpose of the CRC added to a MAC block by the lower MAC is to enable the MAC at the receiving 
side of the air interface to detect whether errors have been introduced into the message during 
transmission. Therefore, the receiving lower MAC shall extract the decoded CRC and shall calculate a 
CRC on the remainder of the data as in the transmitting case. The two CRCs shall be compared. If they 
are not identical, the CRC fail parameter in the TMV-UNITDATA indication primitive shall inform the 
receiving upper MAC that an error has occurred. 

Upon reception of a MAC block as indicated with the CRC fail parameter in the TMV-UNITDATA indication 
primitive, the upper MAC shall discard the incoming data. However, the upper MAC may use the CRC fail 
information to update its statistics on error measurement. 

Upon reception of a MAC block as indicated with the CRC pass parameter in the TMV-UNITDATA 
indication primitive, the upper MAC shall further check that the incoming PDU or PDUs are valid by 
inspecting the headers. 

23.4.4 Power control 

23.4.4.1 Overall process 

Adaptive RF power control shall be used by the MS. It allows the system to minimise the transmit power 
required by the MS whilst maintaining the quality of the radio uplink. By minimising the transmit power 
levels, interference to co-channel and adjacent channel users is reduced and MS power consumption 
could be reduced. 

Two methods of adaptive RF power control may be used. The first method, known as open loop power 
control, shall be implemented in the MS. Using this method, the MS shall adjust its transmit power based 
on the power level or equivalent signal quality being received by the MS on the downlink from the BS. The 
second method, known as closed loop power control, shall be supported by the MS and may be 
implemented in the BS. Using this method, the MS shall adjust its transmit power as instructed by the BS. 
The BS shall calculate the optimal MS transmit power, for example based upon the power level being 
received on the uplink from that MS. The exact method of measurement and calculation in the BS are 
outside of the scope of this ETS. 

These methods are described in more detail in the following subclauses. Adaptive RF power control shall 
not be used to control the BS transmit power. 
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23.4.4.2 MS open loop power control 

Open loop power control shall be implemented in the MS. The power level shall be controlled for all 
transmitted bursts including random access messages. An MS, when camped on a cell, shall obtain the 
MS_TXPWR_MAX_CELL and ACCESS.PARAMETER parameters by decoding the SYSINFO PDU 
broadcast by the BS on the BNCH. For any random access, reserved access or traffic transmissions, the 
MS shall use the transmit power level supported by the MS that is the closest to P MS , where P MS is 
defined by: 

P MS = MIN ( MS_TXPWR_MAX_CELL, ACCESS_PARAMETER - RSSI ) (78) 

where: MS_TXPWR_MAX_CELL = Maximum MS transmit power allowed in the cell; 

ACCESS_PARAMETER = Parameter for transmit power calculation; 

RSSI = Averaged signal level received by the MS or an equivalent signal quality 
measurement. 

All values are expressed in dBm. 

NOTE: ACCESS_PARAMETER is based on BS power and configuration and on the required 
mean power level received at the BS. 

The MS, while receiving traffic or signalling, shall update P MS for the current serving cell at least every 30 
seconds and, in case of modification, may linearize on a subslot provided for common linearization 
(CLCH). 

The MS, while transmitting, shall update P MS at least every 3 seconds based upon its RSSI 
measurements. The MS shall adjust its transmit power to the level supported by the MS that is the closest 
to P MS , at the latest, immediately following the next CLCH opportunity. 

The only exception to the above rule is in the case of a random access transmission which has the 
highest level PDU priority equivalent to emergency. Then the MS may set the transmit power equal to the 
MS_TXPWR_MAX_CELL parameter for this cell in order to increase the probability of that "emergency" 
random access transmission reaching the BS without being corrupted. 

23.4.4.3 MS closed loop power control 

Closed loop power control may be employed by a BS in order to control the power of an MS transmitting in 
circuit mode on a traffic channel. The MS shall obey power control messages from the BS while the 
MS-MAC is transmitting in U-plane mode. Such power control instructions shall be obeyed only for the 
duration of that U-plane transmission after which the MS shall revert to open loop power control for 
subsequent transmissions. 

When the MS-MAC switches from C-plane to U-plane transmission mode, the BS may control the MS 
transmit power by sending a MAC-RESOURCE PDU, which includes the optional power control element, 
to instruct the MS to increase or decrease its transmit power by the appropriate number of steps. A step is 
equal to 5 dBm as defined in clause 6. The MS shall obey these power control instructions. If the MS is 
instructed to increase its power above the maximum transmit power of that MS then it shall set its power 
to the maximum transmit power. Similarly, if it is instructed by the BS to set its power below the minimum 
step of 15 dBm, then it shall set its power to 15 dBm. The MS shall adjust its power after receiving a 
power control message, at the latest, immediately following the next CLCH opportunity. This power level 
shall take precedence over open loop power control and shall be used for all subsequent traffic and 
signalling transmissions, including any transmissions in frame 18, for the duration of the U-plane 
transmission until one of the following events occurs: 

the MS ends its transmission and switches out of U-plane mode; 

the BS sends a MAC-RESOURCE PDU with the power control element set to "Revert to open loop 
power control". 
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Then the MS shall revert to using the rules defined for open loop power control as defined in the previous 
subclause. During closed loop power control operation, the MS shall continue to maintain its RSSI 
estimate for the downlink so that P MS is always up to date. 

23.4.5 MS linearization 

The ACCESS-ASSIGN PDU shall indicate those uplink subslots that are available for common use for 
linearization. The MS may linearize its transmitter using any subslot that is indicated as a "CLCH subslot", 
without regard to the access code, and even on another physical channel. 

In addition, during frame 18, the MS may linearize on the first subslot of the uplink slot defined by (in 
accordance with clause 9): 

CLCH mapped if: 

FA/= 18 and (MA/+ 7A/)mod 4 = 3 (79) 

This shall provide a linearization opportunity at least every four multiframe periods on each of the four 
physical channels of a carrier. The MS may linearize during these subslots without regard to the AACH 
contents but the BS should set the AACH appropriately to indicate a CLCH opportunity. 

The MS shall keep adequately linearized, so that it is ready at any time to send a message on the current 
RF carrier (for example, a response to a BS paging message) without first needing to use a CLCH 
subslot. This rule shall apply even while the MS is in energy economy mode. 

23.4.6 BS synchronisation 

When an MS moves from one RF carrier to another within a cell, it shall assume that the old frame and 
slot synchronisation apply also on the new carrier. For example, at call set-up, it may immediately linearize 
and use granted slots or subslots using the timing of the old carrier. 

Therefore, the BS shall synchronise the slot, frame and multiframe timing on all its carriers within a cell. 
23.5 PDU transfer for signalling messages (TMA-SAP) 
23.5.1 Random access protocol 
23.5.1.1 Introduction 

The MS-MAC layer uses the random access protocol to initiate information transfer to the BS. The 
random access protocol is generally used for unsolicited MS messages, whereas messages solicited by 
the BS are sent using reserved access. 

The random access protocol is based on slotted ALOHA procedures, with a superimposed access 
, framing structure. By a suitable choice of access parameters, it is possible for the BS to: 

control the collision of access requests from different MSs; 

minimise access delay and traffic loss for a particular traffic loading; 

maintain peak throughput for a particular traffic loading; 

avoid protocol instability; 

dynamically restrict random access to different access priorities, and to selected groups and 
subscriber classes; 

provide simultaneously, independent access grades of service for different groups and subscriber 
classes. 

The random access procedures defined in this subclause are suitable for use on all types of control 
channel. 
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This subclause provides a general overview of the random access protocol. The precise protocol definition 
is contained in subclauses 23.5.1.3 and 23.5.1.4. 

The BS may offer random access opportunities to different sets of MSs in turn by using "Access Codes". 
There is a maximum of four possible access codes (denoted A, B, C and D), and the BS marks each 
access opportunity with the appropriate access code. 

The binding of MSs to access codes is dynamic. The binding defines the minimum valid priority for an 
access code. It may also restrict use of the access code to a set of subscriber classes, or to a group of 
MSs. An MS may use a subslot designated for a particular access code only if the PDU priority (as 
supplied by Layer 3), and the subscriber class parameter or MS identity, conform to the current binding. 

For a particular access code, requests from MSs are invited within "access frames" consisting of a 
number of access opportunities (uplink subslots). 

The random access procedures are based on two types of PDU broadcast by the BS. The PDUs are: 

i) The ACCESS-DEFINE PDU 

This PDU is transmitted at intervals, how often being an operator option. It contains fairly slowly 
changing information about the random access parameters for an access code: 

the priority and MS binding to the access code; 

a parameter (IMM) defining when immediate access is permitted for the first transmission; 
the waiting time (WT) before deciding to re-try; 
the permitted number of random access retries; 
a frame-length multiplying factor; 
the uplink channel configuration. 

ii) The ACCESS-ASSIGN PDU 

This PDU is transmitted in every downlink slot on the AACH, in the broadcast block. It conveys 
information about the usage of the downlink slot in which it appears, and also access rights for the 
corresponding (same-numbered) uplink timeslot of that TDMA frame. When the uplink is in use for 
control signalling, the ACCESS-ASSIGN PDU usually contains two "Access Fields" which convey 
independent access rights for each of the two uplink subslots in the uplink slot. 

The access field defines the allowed access code for the uplink subslot. It also may include a 
frame-length parameter. Otherwise, it may indicate that the uplink subslot is reserved for use by 
one MS and is therefore not available for random access; or it may assign the subslot for common 
linearization. 

Also, the SYSINFO PDU (the content of BNCH) may include some default parameters to be assumed, for 
Access Code A, by MSs that have acquired the main carrier (until receipt of ACCESS-DEFINE PDUs). For 
systems that do not need multiple access codes, the facilities provided by the SYSINFO PDU may be 
adequate, so that the ACCESS-DEFINE PDU is not used. 

The BS may optimise the system performance by varying the access code bindings, the frame-length and 
the other access parameters. The choice of parameters will depend on the type of system and the traffic 
mix. 

The basic format of the random access channel is illustrated in figures 143 to 145 inclusive. 

NOTE: In these representations, the detailed TDMA frame structure (e.g. with a control 
timeslot and three traffic timeslots per TDMA frame) is not shown. The uplink control 
subslots (half timeslots) for this control channel are shown as if they were contiguous. 
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Figure 143 illustrates an example of designation of uplink subslots, showing multiple access codes and 
reserved subslots. The designation is performed using the AACH, with one ACCESS-ASSIGN PDU 
defining the use of the two corresponding uplink subslots. 
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Figure 143: Example of subslot structure 

Now consider only those subslots relevant to a particular access code. For these subslots, requests from 
MSs are invited within access frames. The access field in the ACCESS-ASSIGN PDU indicates the 
number of following uplink subslots, for this access code, that constitute an access frame. A special value 
("ongoing frame") is used when the field does not mark the start of a new access frame. 

When a user request is initiated, for example valid for code A, the MS-MAC is permitted to send a first 
random access request in the next code A subslot, provided that this occurs within a designated time. 
Otherwise the MS-MAC waits for an ACCESS-ASSIGN PDU containing a frame marker for code A, and 
then chooses a subslot randomly from this access frame for its random access request. An MS-MAC 
wishing to send a repeat transmission after an unsuccessful access request waits for a new frame marker 
before choosing another subslot randomly from that frame. 

This procedure is illustrated in figures 144 and 145, in which the subslots shown are only those control 
subslots marked for random access by code A. WT is the re-try time when the MS-MAC decides that its 
access request has failed. 

In figure 144, the BS chooses to mark rolling access frames, with a new access frame marked in every 
subslot so that the access frames clearly overlap. In figure 145, the BS chooses to mark discrete access 
frames, by using the "ongoing frame" value (here denoted by *) to indicate continuation. The MS 
procedures operate independently of this BS choice. 
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Figure 144: Example of random access procedure (BS using rolling access frames) 
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Figure 145: Example of random access procedure (BS using discrete access frames) 

In either case, the BS may monitor activity on the uplink channel in the subslots assigned to the access 
code, and may vary the frame-length to prevent excessive collision and to minimise access delays. Under 
normal conditions, the frame-length can be short. Then, when collision is detected, the BS may increase 
the frame-length dynamically according to its estimate of the backlogged traffic. This allows rapid 
smoothing of traffic transients. 



23.5.1 .3 Access control facilities for BS 



See also the MS random access protocol: subclause 23.5.1 .4. 

23.5.1 .3.1 Transmission of ACCESS-DEFINE and ACCESS-ASSIGN PDU 



The BS may transmit ACCESS-DEFINE PDUs at intervals decided by the operator, and shall transmit the 
ACCESS-ASSIGN PDU in every downlink timeslot. The formats of these PDUs are defined in clause 21. 
Between them, these PDUs shall indicate: 



the configuration of the random access channel for this control channel; 
the valid priorities and the MSs eligible for each uplink subslot; 



the frame-lengths to be used; and 

other ALOHA re-try parameters. 

Also, the BS may include in the SYSINFO PDU some default random access parameters to be assumed 
by MSs, for access code A, until receipt of ACCESS-DEFINE PDUs. 



The following points may be noted. 

a) MSs that have missed ACCESS-DEFINE PDU broadcasts will be unaware of some of the current 
access restrictions and will be applying the limitations of the last received ACCESS-DEFINE PDU 
(or SYSINFO information). 

b) MSs count subslots in access frames using only the ACCESS-ASSIGN PDUs that they receive. 
Therefore, in case of un-decodeable ACCESS-ASSIGN PDUs, not all MSs will count the subslots in 
exactly the same way. 

c) Use of the ACCESS-DEFINE PDU is not required if the facilities provided within the SYSINFO PDU 
are adequate for a particular system. 

d) The "Timeslot Pointer" element in the ACCESS-DEFINE PDU (and SYSINFO) allows the BS to 
define those timeslots per TDMA frame that can be used for random access by MSs on this control 
channel, independently of the downlink channel configuration. For example, the BS may define an 
extended random access channel, allowing additional random access opportunities. 

The ACCESS- ASSIGN PDU then indicates (on a slot-by-slot basis) whether each uplink random 
access slot is available for common use or only for MSs on an assigned channel. This allows 
flexible use of the uplink e.g. in case of an extended random access channel for the MCCH, or in 
case of minimum mode. 
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e) The BS designer should note the default assumptions for an MS when it acquires the main carrier 
or changes channel within the cell. 

23.5.1 .3.2 BS response to access request 

After receiving an MS random access request, the BS should respond with a MAC-RESOURCE PDU 
indicating successful random access. The response may be sent in the corresponding downlink timeslot in 
the next TDMA frame, or it may be delayed; the WT parameter in the ACCESS-DEFINE PDU defines the 
time the MS-MAC will wait before deciding to retransmit (see subclause 23.5.1 .4). 

The BS should return the response in a timeslot on the MS's downlink control channel. If there is any 
possible ambiguity about the requesting MS's downlink configuration, the BS may return the response in 
more than one downlink slot. 

If the BS is ready to return an LLC response or a layer 3 message (e.g. D-CALL PROCEEDING or 
D-CONNECT ACKNOWLEDGE) to the requesting MS at the time when it sends the MAC-RESOURCE 
response PDU, then it may carry a TM-SDU in the MAC-RESOURCE PDU, otherwise it should send a 
dedicated MAC response PDU. 

23.5.1 .3.3 Reserving subslots on uplink 

During an access frame, the BS may transmit PDUs that demand a response from a specific MS (e.g. the 
D-SETUP PDU). To allow the MS to respond without making a random access, the BS may reserve a 
subslot or slot(s) for the response. The ACCESS-ASSIGN PDU shall indicate which subslots are reserved 
and therefore not available for random access. The MS for which a subslot or slot(s) are reserved shall be 
informed in the downlink signalling channel. 

The ACCESS-ASSIGN PDU shall also indicate subslots that are available for common use for 
linearization (and therefore not available for random access). 

23.5.1 .4 MS-MAC random access protocol 

The general random access procedure is described in subclauses 23.5.1.4.1 to 23.5.1.4.9; this procedure 
covers normal operation on one control channel (main, secondary or extended). Then any variations in 
operation for different channel configurations are described in subclauses 23.5.1 .4.10 to 23.5.1 .4.14. 

23.5.1 .4.1 Reception of ACCESS-DEFINE PDU 

The MS-MAC shall continuously receive the downlink control channel, looking for ACCESS-DEFINE 
PDUs, within the constraints of the energy economy regime and the cell re-selection procedures. The 
downlink slot(s) appropriate to this control channel are known from the SYSINFO PDU (BNCH) or from 
the "Timeslot Assigned" element in the MAC-RESOURCE PDU that sent the MS to the channel. An 
ACCESS-DEFINE PDU defines access restrictions and access parameters for one access code. 

On receipt of an ACCESS-DEFINE PDU, the MS-MAC shall note the minimum valid priority for the access 
code, also, if included, the MS-MAC shall note the eligible subscriber classes or group address. If the 
ACCESS-DEFINE PDU does not include a "subscriber class bit map" element, the MS-MAC shall assume 
that there is no subscriber class restriction. If the ACCESS-DEFINE PDU does not include a "GSSI" 
element, the MS-MAC shall assume that there is no address restriction. 

The MS-MAC shall note the ALOHA parameters (IMM, WT, Nu ( frame-length factor). It shall also note 
from element "Timeslot Pointer" which uplink slots are potentially available for random access i.e. the valid 
pattern for monitoring the AACH for access invitations. If Nu is set to "0" in the ACCESS-DEFINE PDU, 
this indicates that the access code is not available for use. 

The MS-MAC shall comply with the received ACCESS-DEFINE parameters for random access attempts 
on this access code and control channel. Each parameter set shall remain valid until updated by a 
subsequent ACCESS-DEFINE PDU for this access code and with the same setting of the "Common or 
assigned control channel flag", received on this control channel. 
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NOTE 1: A subsequent ACCESS-DEFINE PDU for this access code overwrites the previous 
definition even if the addressing mechanism, i.e. subscriber class bit map, GSSI or 
neither, is not the same. 

An MS on the MCCH or on a common SCCH shall ignore any received ACCESS-DEFINE PDUs 
containing "Common or assigned control channel flag" = "1" (i.e. assigned). Similarly, an MS on a channel 
assigned for SCCH or for a circuit mode call shall ignore any received ACCESS-DEFINE PDUs containing 
"Common or assigned control channel flag" = "0" (i.e. common). 

NOTE 2: The "Timeslot Pointer" element may give a bit map of the appropriate timeslots for the 
random access channel for this control channel, or it may be set to a 0000 2 n , i.e. same 
as downlink slot assignment. The latter means: 

slot 1 if the MS is on the MCCH; 

the appropriate slot for this MS when common SCCHs are in use; or 

the same timeslot number(s) as for the "Timeslot Assigned" element from the 
MAC-RESOURCE PDU in the case of an assigned channel. 

23.5.1 .4.2 Reception of ACCESS-ASSIGN PDU 

If the MS-MAC wishes to send a random access message, and knows a valid access code for the 
message, it shall attempt to decode the appropriate downlink AACH which contains the ACCESS-ASSIGN 
PDU. The MS should look for AACH in all the slots defined by element "Timeslot Pointer" from the 
ACCESS-DEFINE PDU, or the default value from the SYSINFO PDU, in all frames 1 to 18. 

If an ACCESS-ASSIGN PDU contains two access field elements then "Access Field 1" conveys access 
rights to subslot 1 in the corresponding uplink slot, i.e. the same-numbered uplink timeslot of that TDMA 
frame. "Access Field 2" conveys independent access rights to subslot 2 in the uplink slot. 

If an ACCESS-ASSIGN PDU contains only one access field, this conveys access rights to both subslots of 
the corresponding uplink slot as follows: 

a) the same access code shall be assumed for both subslots; 

b) when the access field indicates "Reserved Subslot", it shall be assumed that both subslots are 
reserved; 

c) when the access field indicates "CLCH Subslot", it shall be assumed that subslot 1 may be used for 
linearization, and subslot 2 is reserved; 

d) when the access field indicates "Ongoing Frame", it shall be assumed that ongoing frame applies to 
both subslots; 

e) when the access field indicates a frame marker base frame-length of > 1 subslots, it shall be 
assumed that the frame marker base frame-length applies to subslot 1 , and that "Ongoing Frame" 
applies to subslot 2. 

If an ACCESS-ASSIGN PDU contains no access field (i.e. traffic on uplink) then both the corresponding 
uplink subslots shall be regarded as reserved. 

If an MS on the MCCH or on a common SCCH receives an ACCESS-ASSIGN PDU indicating that the 
uplink slot is designated as "Assigned only", then both the corresponding uplink subslots shall be regarded 
as reserved. 

If an MS on an assigned channel (assigned for SCCH or for a circuit mode call) receives an ACCESS- 
ASSIGN PDU indicating that the uplink slot is designated as "Common only", then both the corresponding 
uplink subslots shall be regarded as reserved. 

If an ACCESS-ASSIGN PDU is un-decodeable then both the corresponding uplink subslots shall be 
regarded as reserved. 
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NOTE: As defined in clause 9, the start of the TDMA frame (and multiframe and hyperframe) 
on the uplink is delayed by a fixed period of two timeslots from the start of the TDMA 
frame (or multiframe or hyperframe) on the downlink. So the ACCESS-ASSIGN PDU 
in a downlink slot conveys access rights to the corresponding uplink slot, which is two 
slots later. 

23.5.1 .4.3 Initiating a random access 

The MS shall only make one random access attempt at a time, per control channel. A random access 
attempt refers to the period from initiation of the random access procedure until a response is received or 
the procedure is abandoned. 

When the MS has individually addressed signalling messages to send, as indicated by the 
DATA-IN-BUFFER signal from the LLC, the MS-MAC may initiate the random access procedure if it: 

a) does not have a reserved subslot or slot(s) already granted to it on this control channel; and 

b) has not already indicated to the BS that it has a signalling requirement on this control channel (by 
asking for a reserved subslot or slot(s)). 

Also, the MS-MAC may initiate the random access procedure if it does not have a reserved subslot or 
slot(s) already granted to it, and the LLC indicates that a new emergency message has just been received 
from layer 3, as indicated by the priority parameter in the DATA-IN-BUFFER signal. 

NOTE: This exception allows the MS-MAC to cut short the reserved access waiting time-out 
T.206 in case of emergency; see subclause 23.5.2.4. 

The random access request shall be sent using the MAC-ACCESS PDU, fitting within a single subslot on 
the uplink (SCH/HU) and containing a TM-SDU or first fragment if appropriate. Any TM-SDU to be sent, or 
TM-SDUs if using association, are received from the LLC in the TMA-UNITDATA request primitive. 

If the MS has any further signalling to send on this control channel, the MS-MAC shall include a request 
for reserved capacity in the MAC-ACCESS PDU. 

When the MS-MAC is required to initiate a random access, it shall comply with the access parameters. If 
the access request is not valid for any of the current access codes as specified in subclauses 23.5.1.4.1 
and 23.5.1.4.4, the MS-MAC may immediately abandon the random access attempt, reporting the failure 
to the LLC using the TMA-REPORT indication primitive. 

23.5.1 .4.4 Checking for appropriate access code 

When the MS-MAC wishes to send a non-emergency message, it shall not use a subslot designated for a 
particular access code unless the following criteria are all satisfied: 

a) the PDU priority, as supplied in the TMA-UNITDATA request primitive, is equal to or higher than the 
minimum priority for this access code; 

b) if subscriber class is restricted for this access code, the subscriber class information, as supplied in 
the TMA-UNITDATA request primitive, is eligible for this access code; 

c) if address is restricted for this access code: the MS belongs to the designated group. 

For an emergency message, the same criteria shall apply for access codes B, C and D. However, the MS 
may use access code A for an emergency message without checking the above criteria. 

For a message sent with an USSI, criterion b) need not be checked. 

NOTE 1 : In criterion b), the eligibility for subscriber class requires that, for at least one class, the 
class is invited by the ACCESS-DEFINE PDU, i.e. there is a "1" in the appropriate 
position, and the MS belongs to that class. 

NOTE 2: The message is an "emergency message" if the PDU priority parameter in the TMA- 
UNITDATA request indicated the highest priority, i.e. 7. 
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NOTE 3: The USSI exception is included because the MS will not have subscriber class 
information for this network at this time. This exception applies also to an MS if it has 
not yet registered and did not receive subscriber class information at subscription. 

23.5.1.4.5 First try procedure 

There is a special procedure for the first random access transmission. 

The MS-MAC shall transmit its random access request in the first uplink slot in which one or both subslots 
are valid access opportunities, i.e. an appropriate access code and common/assigned designation, and 
subslot not reserved nor assigned for linearization, if: 

a) it is an emergency message; or 

b) parameter IMM = 15; or 

c) 1 < IMM < 14, and the valid access opportunity occurs within the IMM TDMA frames following the 
initiation of the random access procedure. 

If both the subslots in the uplink slot are valid access opportunities, the MS-MAC shall choose one of the 
two subslots randomly. This rule applies only to this first try procedure. 

If the above conditions are not met, then the MS-MAC shall choose a subslot from a new access frame 
(see subclause 23.5.1.4.6). 

If a complete TM-SDU is contained within the MAC-ACCESS PDU, then the MS-MAC shall report to the 
LLC when the first random access transmission has been sent using the TMA-REPORT indication 
primitive. 

23.5.1 .4.6 Choosing from a new access frame 

An MS-MAC that requires to select a subslot from a new access frame shall wait for a suitable access 
frame marker i.e. an ACCESS-ASSIGN PDU with an access field that contains: 

a frame marker ("Base Frame-length" of > 1 subslots); and 

an appropriate uplink slot designation (common/assigned); and 

an appropriate access code (as defined in subclause 23.5.1 .4.4); 

with the most recently received access code parameters enforced at this time. 

The MS-MAC shall then select a subslot randomly from the specified access frame. That is, it shall 
choose a subslot randomly between 1 and frame-length using a uniform distribution, where: 

if the "framelength factor" for this access code = 0 
then Framelength = 1 * Base Framelength 
else Framelength = 4 * Base Framelength. 

The MS-MAC shall transmit its access request in the chosen subslot, unless the random access attempt 
is abandoned (see subclause 23.5.1 .4.9). 

23.5.1 .4.7 Counting subslots in an access frame 

The uplink subslot corresponding to the frame marker access field is defined as the first subslot in the 
access frame. 

When counting further access subslots to its chosen subslot in the access frame, the MS-MAC shall count 
a subslot only if: 

a) it was indicated by element Timeslot Pointer" in the ACCESS-DEFINE PDU; and 

b) the corresponding ACCESS-ASSIGN PDU is de-codeable; and 
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c) the uplink slot designation (common/assigned) is appropriate for the MS; and 

d) the subslot is marked with the appropriate access code, i.e. the access code used when choosing 
from the access frame; and 

e) the subslot is not designated as reserved or assigned for linearization. 

NOTE: Subslots for this code designated as "ongoing frame" are counted, and also subslots 
starting new access frames; a new access frame marker does not alter a subslot 
choice already made. 

23.5.1 .4.8 Re-try procedure 

After sending an access request, the MS-MAC shall wait for a response from the BS, i.e. a 
MAC-RESOURCE PDU on the downlink control channel, containing the same address as in the access 
request and with the "random access flag* indicating successful random access. If a complete TM-SDU 
was contained within the MAC-ACCESS PDU, the MS-MAC shall report the success to the LLC using the 
TMA-REPORT indication primitive. Then, if the received MAC-RESOURCE PDU contains a TM-SDU, the 
MS-MAC shall deliver that TM-SDU to the LLC using the TMA-UNITDATA indication primitive. 

The MS-MAC shall look for the response in all downlink slots appropriate to this control channel, as 
indicated by the SYSINFO PDU or by the MAC-RESOURCE PDU that sent the MS to the channel. The 
first potential slot in which the response may be received is the corresponding downlink slot in the next 
TDMA frame, i.e. the same timeslot number as the request slot if that slot is appropriate to the downlink 
control channel. This allows the MS one timeslot duration for switching from transmission to reception. 

If a response is not received within the WT downlink signalling opportunities after transmission of its 
access request, the MS-MAC shall assume that the transmission has failed. Then it shall either: 

a) abandon its random access attempt (see subclause 23.5.1 .4.9 point a); or 

b) select a further subslot randomly from a new access frame, as in subclause 23.5.1 .4.6, and using a 
frame marker ACCESS-ASSIGN PDU received in or after the WT'th downlink signalling opportunity 
following the unsuccessful access request. However, if the MS-MAC receives a response before 
sending a repeat message, it shall accept the response and not retransmit. 

When counting slots (i.e. signalling opportunities) for timer WT, the MS-MAC shall count only one slot per 
TDMA frame, namely the downlink slot with the same timeslot number as the request slot or, if that slot is 
not appropriate to the downlink control channel, then the next slot that is appropriate to the downlink 
control channel. 

On an assigned channel, the MS-MAC shall count the downlink slot only if it is available for control. 
Downlink slots in frames 1-17 for which the AACH or, last received AACH in frames 1-17, indicates 
downlink user traffic TCH should not be counted in the time-out WT. However, The BS may choose to 
send the response by stealing from the downlink TCH. 

NOTE 1 : Downlink user traffic in frames 1 -1 7 is indicated by Header * "00 2 N and downlink usage 
marker > "0001 00 2 ". 

NOTE 2: The above procedure allows for possible cases of independent allocation of uplink and 
downlink. 

NOTE 3: As defined above, the MS looks for a response in all downlink slots appropriate to that 
channel. However a maximum of one slot per TDMA frame is counted for time-out 
WT. This is equivalent to the method for timers T.202, T.206 and some LLC timers. It 
contrasts with the method for counting uplink opportunities for the granting delay and 
capacity allocation for reserved access, when all slots on a multi-slot channel are 
counted; and with the method for counting access subslots in an access frame, when 
alt appropriate subslots are counted. 
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23.5.1 .4.9 Abandoning random access attempt 

The MS-MAC shall cease attempting random access if it receives a response from the BS, as described 
in subclause 23.5.1 .4.8, or if any of the following occurs: 

a) the MS-MAC has sent the current maximum permitted number of random access transmissions 
without receiving a response; the maximum number of transmissions is Nu for a message with PDU 
priority 0 to 6, or 2 * Nu for a message with PDU priority 7. The failure shall be reported to the LLC 
using the TMA-REPORT indication primitive; 

b) a time T.205 has elapsed since initiation of the random access procedure. The failure shall be 
reported to the LLC; 

c) the MS-MAC receives a TMA-CANCEL request primitive from the LLC, cancelling transmission of 
this message. The MS-MAC shall abandon the random access attempt whether or not it has sent 
any transmissions, reporting the state of transmission to the LLC; 

d) the MS-MAC receives a MAC-RESOURCE (or MAC-END) PDU that does not indicate successful 
random access but grants a reserved subslot or slot(s), individually addressed to this MS. The 
MS-MAC shall send a PDU (or PDUs) in the reserved capacity, i.e. its own request and/or the 
message demanded by the BS. If the MS has any further signalling ready to send on this control 
channel, the MS-MAC shall include the "reservation requirement 0 element in its transmission; 

if a complete TM-SDU is transmitted, the MS-MAC shall report to the LLC that the message has 
been sent by reserved access. 

Also, if the access request becomes ineligible for the current definition of the access codes, the MS-MAC 
may abandon the random access attempt, reporting the failure to the LLC. 

If the MS-MAC abandons a random access attempt without having received a response from the BS, it 
shall not initiate any new random access attempt until any ongoing WT timer from the last request has 
expired. 

23.5.1 .4.1 0 Random access operation after acquiring main carrier 

The MS-MAC shall make the following assumptions about the random access parameters on first 
acquiring a main carrier or receiving a channel allocation for a new cell. 

If the MS-MAC has received the "default definition for access code A" element in the SYSINFO PDU then 
it shall assume the most recently received SYSINFO parameters for access code A, and with no MAC 
subscriber class restriction or address restriction, until it receives an ACCESS-DEFINE PDU for access 
code A. Otherwise it shall not use access code A until it receives either the SYSINFO default definition for 
access code A or an ACCESS-DEFINE PDU for access code A. 

The MS-MAC shall not use access code B, C or D until it receives the appropriate ACCESS-DEFINE 
PDU. 

NOTE 1 : These parameters apply both to the MCCH and to a common SCCH. 

There is no time limit on the validity of use of the SYSINFO parameters, since some BSs may choose 
never to send the ACCESS-DEFINE PDU relying solely on the SYSINFO default definition for Code A. 
Until receipt of a "common" ACCESS-DEFINE PDU for Code A, the MS shall assume the most recently 
received SYSINFO parameters. After receipt of a "common" ACCESS-DEFINE PDU for Code A, the MS 
shall ignore any access parameters received in SYSINFO PDUs, reverting to the procedure in 
subclause 23.5.1.4.1. 
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NOTE 2: The validity of use of the SYSINFO parameters on the MCCH or a common SCCH is 
not affected by receipt of an ACCESS-DEFINE PDU with "Common or assigned 
control channel flag" = "1" (i.e. assigned). Receipt of an "assigned" ACCESS-DEFINE 
PDU for Code A while the MS is on the MCCH or a common SCCH does not affect the 
validity of the SYSINFO parameters. Receipt of an "assigned" ACCESS-DEFINE PDU 
for Code A while the MS is on an assigned channel over-rides the SYSINFO definition 
while the MS is on that assigned channel, but does not affect operation when the MS 
returns to the MCCH or to a common SCCH. 

23.5.1 .4.1 1 Random access operation on a new channel 

When an MS is sent to a new channel within the cell, it shall make the following assumptions about the 
random access parameters, until updated by ACCESS-DEFINE PDUs or the SYSINFO definition. 

a) When changing channel to the MCCH or to a common SCCH, the MS-MAC shall assume that all 
random access parameters except the Timeslot Pointer" are equal to those used when the MS- 
MAC last received either the MCCH or a common SCCH, i.e. parameters as received in SYSINFO 
and/or ACCESS-DEFINE PDUs. This rule applies both when the BS has changed the number of 
common SCCHs in use and when the MS-MAC returns from an assigned channel. 

The MS-MAC shall assume that the random access channel uses the same timeslot as the current 
downlink assignment. 

b) For an assigned channel (either for SCCH or for a circuit mode call): 

Timeslot Pointer", i.e. the same timeslot number(s) as for the "Timeslot Assigned" from the 
MAC-RESOURCE PDU. 

Other parameters, i.e. equal to those on the old channel except that, for access code A, the 
MS-MAC shall assume "Frame-length Factor" = "0", "Minimum Priority" = OOQ2 and no 
subscriber class restriction or address restriction. 

The MS-MAC may continue an ongoing random access attempt on the new channel, but shall choose a 
subslot from a new access frame using an appropriate frame marker received on the new channel. 

The random access parameters shall ail be updated on receipt of an appropriate ACCESS-DEFINE PDU 
on that channel. If the MS is on the MCCH or a common SCCH, and is still using the SYSINFO default 
definition, then the MS shall update the parameters on receipt of a new SYSINFO definition. If the MS is 
on an assigned channel, and is still using the SYSINFO default definition on that channel, then the MS 
shall update the parameters on receipt of a new SYSINFO definition except for parameters "Timeslot 
Pointer", "Frame-length Factor" and "Minimum Priority" for which it shall retain the values given in b) 
above. 

23.5.1 .4.1 2 Random access operation on ACGH 

If the MS-MAC wishes to send a random access message on a channel allocated for a circuit mode call, it 
shall obey the normal procedures but with the following differences. 

If the MS is transmitting traffic in frames 1-17 and sends a random access request in frame 18 then, when 
counting downlink slots for waiting time WT, the MS shall count only those slots that it is required to 
monitor, according to the assigned monitoring pattern(s), and are available for control (see 
subclause 23.5.1.4.8). 

For a multi-slot channel, and if the MS is not frequency full duplex, and if there is currently traffic on the 
downlink, then the MS is not required to transmit a random access request if it would thereby miss 
downlink traffic. The MS may regard unsuitable uplink subslots as reserved. 

23.5.1 .4.1 3 Random access operation in minimum mode 

During minimum mode, the MS-MAC shall follow the defined minimum mode rules for monitoring and 
decoding the downlink for signalling messages - in slot 1 of frames 1-17 and in its designated minimum 
mode slot in frame 18. 
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When an MS-MAC enters minimum mode, the most recently received access definitions shall apply. If the 
MS-MAC then receives ACCESS-DEFINE PDUs in the downlink slots that it is required to monitor, it shall 
obey the ACCESS-DEFINE definition for PDUs containing "Common or assigned control channel flag" = 
"0" (i.e. common); but shall ignore ACCESS-DEFINE PDUs containing "Common or assigned control 
channel flag" = "1" (i.e. assigned). 

If an MS-MAC in minimum mode wishes to send a random access message, the valid pattern for 
monitoring the AACH for access invitations and for counting subslots in an access frame is: 

In frames 1 -1 7: the slot(s) defined by the current setting of "timeslot pointer"; 

In frame 18: all four slots. 

Only those uplink slots marked in the ACCESS-ASSIGN PDU as available for common access are 
applicable. 

The procedures defined in preceding subclauses for choosing a subslot for the first and subsequent 
random access transmissions shall apply. When counting downlink slots for waiting time WT, the MS shall 
count only its designated minimum mode frame 18 slot. However, the BS may choose to send the 
response in slot 1 of the assigned channel during frames 2 to 17, either by stealing or within the assigned 
channel's FACCH (as described in subclause 23.3). 

NOTE: The above minimum mode procedure applies only to those MSs that are in common 
control mode and monitoring the MCCH. It does not apply to MSs on an assigned 
channel. 

23.5.1 .4.1 4 Random access operation on time-shared control channel 

On a time-shared MCCH, the MS-MAC shall follow the defined rules for monitoring and decoding the 
downlink for signalling messages. 

If the MS-MAC wishes to send a random access message, it shall obey the normal procedures but with 
the following differences. 

The rules for monitoring the downlink for the ACCESS-ASSIGN PDU (according to element 
"Timeslot Pointer") shall apply only to the frames reserved for this BS and the common frames. 

For 1 < IMM < 14, IMM shall be replaced by: 

IMM * 12/TS-RES, for TS-RES = 1 , 2, 3, 4, 6; 

IMM * 36;TS-RES, for TS-RES = 9, 12, 18; 

where TS-RES is the number of reserved frames per two multiframes for this BS. 

When counting downlink slots for waiting time WT, the MS shall count only slot 1 of the frames 
reserved for this BS. However, the BS may choose to send the response in slot 1 of one of the 
common frames. 

For a time-shared common SCCH, "slot 1" in the above shall be replaced by the appropriate slot number 
on the main carrier. 

23.5.2 Reserved access 

The random access protocol is generally needed when the MS-MAC wishes to initiate a transaction. 
However, when an MS-MAC is required to send a solicited message or when it has further signalling to 
send after the initial access, the BS may reserve slots for that particular MS. 

The ACCESS-ASSIGN PDU (on the AACH) indicates which subslots are reserved and therefore not 
available for random access by other MSs. The MS-MAC for which a subslot or slot(s) are reserved is 
informed on the downlink signalling channel, using the MAC-RESOURCE or MAC-END PDU. 
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This subclause describes the MS procedures for requesting reserved slots, and the procedures for 
granting and using reserved slots. 

23.5.2.1 Reservation requirement 

The MAC-ACCESS, MAC-DATA, MAC-END-HU and MAC-END PDUs on the uplink all allow the MS-MAC 
to indicate its reservation requirement on this control channel. The "reservation requirement" element is 
an optional element and shall not be included unless the MS has further signalling ready to send. 

If the MS has further signalling to send on this control channel, the MS-MAC shall include the "reservation 
requirement" element whenever it transmits an SCH/HU or SCH/F MAC block containing a MAC- 
ACCESS, MAC-DATA, MAC-END-HU or MAC-END PDU. If PDU association is used within the MAC 
block then the "reservation requirement" element shall be included in the last PDU in the MAC block. 

The "reservation requirement" element shall indicate the MS's estimate of the total capacity required for 
any further individually addressed signalling messages (basic link or advanced link) that it currently has 
ready to send on this control channel. The method for the MS-MAC to calculate the required capacity for a 
fragmented message is described in subclause 23.4.2.1 .2. The required capacity for other signalling ready 
to send is known from the "Amount of data in LLC buffer" parameter in the DATA-IN-BUFFER signal 
received from the LLC. 

NOTE 1 : The reservation requirement indicates the total amount of C-plane signalling that the 
MS wishes to send, irrespective of whether or not the MS has already been granted 
some future slots. The reservation requirement procedure applies only to signalling 
messages to be sent with an individual address, i.e. the MS's ISSI, ASSI, SMI or 
corresponding event label. Group call presence indication messages are treated 
separately, and are not included in the reservation requirement. 

The MS-MAC may indicate a reservation requirement of one subslot, or one or more full slots (as shown 
in clause 21). The required number of slots is coded in a non-linear format. If the MS's requirement cannot 
be represented exactly within the defined format, the MS-MAC shall round down to the next lower valid 
number of slots, except possibly in the case of a MAC-ACCESS or MAC-DATA PDU containing the start 
of fragmentation. In the case of the start of fragmentation, the reservation requirement shall cover at least 
the capacity needed for the remainder of the fragmented message. 

NOTE 2: The above exception is needed for fragmented messages because the MAC-FRAG 
PDU cannot include a "reservation requirement" element. Therefore, if the MS needs 7 
slots to send the rest of the TM-SDU, it asks for 8 slots (or more if it has other 
signalling to send); or, if it needs 9 slots to send the rest of the TM-SDU, it asks for 10 
slots (or more). In all other cases, the "rounding down" rule applies. 

23.5.2.2 Slot granting 

The BS may allocate reserved slots to an MS either: 

a) after receiving a request for reserved capacity from the MS; or 

b) when the BS sends the MS a message that requires a response. 

The BS shall perform the allocation by including the "slot granting" element in a MAC-RESOURCE or 
MAC-END PDU sent to the MS. The "slot granting" element is an optional element, included only when 
required. 

In case b), the "slot granting" element will generally be included in the same downlink PDU as the invoking 
message. For a fragmented downlink TM-SDU, the grant may be included in either the MAC-RESOURCE 
or the MAC-END PDU. 

For the MAC-RESOURCE PDU, the slot grant shall refer to the MS addressed in the MAC header. For the 
MAC-END PDU, the slot grant shall refer to the MS receiving the fragmented message addressed in the 
MAC-RESOURCE PDU that contained the first fragment. 

The "slot granting" element shall be sent by the BS, and understood by the receiving MS-MAC, in the 
format shown in clause 21. It shall consist of two sub-elements: 



Page 478 

ETS 300 392-2: March 1996 

1 ) capacity allocation: 

this element shall indicate the amount of reserved capacity that is granted on the uplink 
control channel. It may indicate either a single subslot or one or more full slots; 

2) granting delay: 

this element shall indicate the time of the start of the reservation. It shall have one of the 
following forms: 

start in the next uplink slot on this control channel. For both single-slot and multi-slot 
channels, this shall refer to the same-numbered uplink timeslot as the slot containing 
the slot grant, in the same TDMA frame; 

delay for the specified number of opportunities for reserved access on this uplink 
control channel. (See the next subclause for the definition of "opportunities for 
reserved access"); 

start in the first uplink opportunity in the next frame 18. For a slot grant sent in 
frame 18, this shall refer to the following frame 18 (after this one); 

wait for another slot grant. This form does not actually grant slots at this time, but shall 
serve to restart the MS's timer T.206, thereby preventing the MS-MAC from reverting 
to random access. 

After any granting delay, a grant for one subslot or slot shall apply to the next slot on this uplink control 
channel. For a subslot grant, the "capacity allocation" element shall indicate whether the MS shall use the 
first or second subslot. 

When several slots are granted, these shall occupy successive slots on this uplink control channel (after 
any granting delay). 

If the MS-MAC receives multiple slot grants for an individual address or valid event label, it shall assume 
that its current allocation is the combination, i.e. union, of slot grants on this control channel. 

Capacity that has been granted cannot be withdrawn by the BS. However, if the MS indicates that it has 
no further signalling to send (see subclause 23.5.2.3.1), then the BS may re-use any remaining granted 
capacity for another MS. 

23.5.2.2.1 Slot granting in normal mode 

On the MCCH, the uplink for reserved access shall occupy only slot 1 of the main carrier. For a capacity 
allocation of more than one slot, this refers to the use of successive slot Vs. 

For a common SCCH, the same rule shall apply, except with the appropriate slot number on the main 
carrier. 

For an assigned SCCH or for an ACCH, the uplink for reserved access shall occupy the timeslot(s) per 
TDMA frame indicated in the "Timeslot Assigned" element from the MAC-RESOURCE PDU that allocated 
the channel. (So, for example, for an assigned SCCH using timeslots 3 and 4, a four-slot granted 
allocation starting in slot 4 of frame 10 occupies also slots 3 and 4 of frame 1 1 and slot 3 of frame 12). 

The granting delay is given in terms of the number of opportunities for reserved access on this control 
channel. So, for a single-slot channel, the granting delay indicates the delay in TDMA frames; whereas, for 
a multi-slot channel, there are two or more opportunities per TDMA frame. 

NOTE 1 : The width of the uplink channel for reserved access is the same as the width of the 
downlink channel. It is defined independently of any extension of the uplink channel for 
random access. 
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NOTE 2: The counting of slots for the granting delay, and the use of granted slots by the MS, is 
defined in absolute terms given the known number of timeslots per TDMA frame for 
this control channel. Checking of the ACCESS-ASSIGN PDU is not required. For 
example, on a channel assigned for traffic, the MS should follow the normal methods 
for counting slots for the granting delay and for using reserved slots. It is the 
responsibility of the BS to avoid granting slots where another MS may be transmitting 
traffic. Therefore, when the uplink is in SACCH so that only frame 18 is available for 
reserved access, the BS should grant only one reserved subslot or slot at a time. 

23.5.2.2.2 Slot granting in minimum mode 

During minimum mode, if the BS sends a slot granting PDU in an MS's designated minimum mode frame 
18 slot, and if that slot is slot 2, 3 or 4, then the BS shall grant only one reserved subslot or slot in that 
PDU. The granted subslot or slot shall be scheduled either in the corresponding uplink slot of that frame 
18 (Granting delay = 0000 2 ) or in the corresponding uplink slot of the following frame 18 (Granting delay = 
1110 2 ). 

If an MS in minimum mode receives a slot granting PDU in slot 2, 3 or 4 of frame 18 that does not 
conform to the above limitations, then it shall ignore the slot grant. 

NOTE: The above limitations apply only to those MSs that are in common control mode, 
having been monitoring the MCCH. They do not apply to MSs on an assigned channel 
that are using slot 2, 3 or 4 of frame 1 8 for their SACCH. 

For a slot grant sent in slot 1 of frames 1-17, or in slot 1 of frame 18, the BS may make a capacity 
allocation of more than one slot; this shall then refer to the use of successive uplink slot 1's (i.e. the 
normal method). 

23.5.2.2.3 Slot granting on time-shared control channel 

On a time-shared MCCH, the BS may send a slot granting PDU either in one of its own reserved frames 
or in a common frame. It may grant single subslots, or one or more full slots. 

The "opportunities for reserved access" for counting the granting delay, or for using a grant for more than 
one slot, comprise the combination of: 

a) slot 1 of the reserved frames for this BS; and 

b) slot 1 of the common frames. 

So the MS shall count/use successive slot 1's, except that it shall skip over frames that are neither 
reserved for this BS nor common. 

For a time-shared common SCCH, "slot 1" in the above procedure shall be replaced by the appropriate 
slot number on the main carrier. 

NOTE: The network is responsible for co-ordinating the use of the uplink on time-sharing cells, 
to avoid collisions in granted slots. 

23.5.2.2.4 BS slot granting operation 

The BS may use the facilities for slot granting defined above. 

After granting a subslot or slots, the BS should mark the equivalent uplink subslots as "reserved" in the 
ACCESS-ASSIGN PDU, thereby preventing other MSs from sending random accesses. For example, 
after granting one slot, the BS should mark the two equivalent uplink subslots as "reserved". 

If the BS does not receive a message in an individually granted subslot or slot, this may be either because 
the MS did not receive the downlink message or because the uplink message was corrupted during 
propagation. The BS may decide to send another slot granting PDU to the MS. In particular, if the BS does 
not receive a message in the first slot of a multi-slot grant, it is recommended that the BS sends another 
slot granting PDU re-granting the remainder of the slots to the same MS, and further slots if appropriate. 
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For slot granting PDUs, as for all downlink PDUs, the BS should take account of any energy economy 
operation in the MS, sending the PDU in a slot where the MS should be listening. 

If the BS wishes to send data to a group, with a low level presence indication from recipient MSs, the BS 
shall include the group address and a slot grant in the MAC PDU that contains the invoking BL-DATA 
message. The slot grant may be for one subslot, or optionally for one or more full slots, though each MS in 
the group will use only one subslot; see subclause 23.5.2.3.2. The methods whereby the BS detects 
transmission in the granted subslot (or slots) are left open for choice by system designers, e.g. 
measurement of received signal strength. 

23.5.2.3 Use of reserved slots 

23.5.2.3.1 Individual address or event label 

If an MS receives a MAC-RESOURCE PDU or MAC-END PDU containing a "slot granting" element for 
one of its individual addresses or for a valid individual event label for this control channel, the MS-MAC 
shall perform the following actions relating to the "slot granting" element. Other actions may be performed 
relating to other elements in the MAC header. 

The MS-MAC shall inspect the "capacity allocation" and "granting delay" elements and shall record which 
subslot or slot(s) are allocated to it, as described in subclause 23,5.2.2. 

If the MS has individually addressed signalling messages to send on this control channel, as known from 
the DATA-IN-BUFFER signal, then the following procedure applies for each allocated subslot or slot: 

for an allocated subslot, the MS-MAC shall use logical channel SCH/HU; it shall send the final 
fragment of a fragmented TM-SDU, or otherwise a message from the LLC, or messages by 
association, except in the following case. If the MS has signalling to send but cannot use a subslot, 
e.g. if it has only full-slot advanced link messages to send, then the MS-MAC shall send a 
MAC-ACCESS PDU containing the "reservation requirement" element and no TM-SDU; 

for an allocated slot, the MS-MAC shall use logical channel SCH/F; it shall send the next fragment 
of a fragmented TM-SDU, or otherwise a message from the LLC, or messages by association. 

After transmitting a complete TM-SDU, or a final fragment, the MS-MAC shall report to the LLC that the 
message has been sent by reserved access, e.g. using the TMA-REPORT indication primitive. 

If the MS has no individually addressed signalling message to send on this control channel then the 
MS-MAC shall send the Null PDU in the allocated subslot or slot. 

After sending the Null PDU, or any SCH/HU or SCH/F MAC block that does not include a "reservation 
requirement" element, the MS shall not use any other capacity that has already been granted to it, whether 
in one slot granting PDU, or more than one. If the MS receives a further slot granting PDU, and if it still 
has no signalling messages to send, then it shall send the Null PDU in the first allocated slot, or in the 
allocated subslot, and shall not use the remainder of the allocation. 

23.5.2.3.2 Group address 

If an MS receives a MAC-RESOURCE PDU or MAC-END PDU containing a "slot granting" element for 
one of its group addresses, the MS-MAC shall perform the following actions relating to the "slot granting" 
element. Other actions may be performed relating to other elements in the MAC header. 

The MS-MAC shall inspect the "capacity allocation" and "granting delay" elements and shall note which 
subslot or slot(s) are allocated, as described in subclause 23.5.2.2. If the MS has a signalling message 
with this group address to send on this control channel then it shall transmit the message in an uplink 
subslot using the MAC-ACCESS PDU: 

a) for a subslot grant, it shall use the allocated subslot; 

b) for a grant of one or more slots (G slots), it shall choose one subslot randomly from the grant, i.e. 
random choice between 1 and 2G using a uniform distribution. 

Otherwise, the MS shall not transmit. 
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NOTE: This procedure is used only for the low level group presence indication. 

23.5.2.4 Reverting to random access 

If the following criteria are all satisfied then the MS-MAC may initiate the random access procedure (see 
subclause 23.5.1): 

a) the MS-MAC has sent a PDU (MAC-ACCESS, MAC-DATA, MAC-END-HU or MAC-END) 
indicating a reservation requirement on this control channel; and 

b) the MS-MAC does not currently have any individually granted capacity on this control channel; and 

c) a time T.206 has elapsed since: 

the last PDU the MS-MAC sent on this control channel, or 

the last slot granting element the MS-MAC received on this control channel containing the 
instruction to "Wait for another Slot Grant", whichever is the later; and 

d) the MS still has signalling messages to send on this control channel (as indicated by the 
DATA-IN-BUFFER signal). 

The random access request shall be sent on SCH/HU using the MAC-ACCESS PDU, containing a 
TM-SDU if appropriate. If the MS has any further signalling ready to send on this control channel, the 
MS-MAC shall include a request for reserved capacity ("reservation requirement" element) in the 
MAC-ACCESS PDU. 

NOTE 1: T.206 must be greater than, or equal to, the fragmentation time-out constant T.202. 

Then, at the time of reverting to random access, the MS-MAC will not be in the 
process of an uplink fragmentation. 

NOTE 2: Time T.206 is counted in downlink signalling opportunities (see annex B). So, for 
example, in minimum mode the absolute time is 18 times its normal value. 

23.5.2.5 Example of reservation process 

This subclause gives an example of the reservation process. 

The MS-MAC has received a TMA-UNITDATA request primitive from the LLC, containing a long TM-SDU 
(length 512 bits). It uses a MAC-ACCESS PDU for the random access, including the first 56 bits of the 
TM-SDU and indicating a "reservation requirement" of two slots. The BS sends a MAC-RESOURCE PDU 
to acknowledge the random access request. The MAC-RESOURCE PDU also includes a "slot granting" 
element, granting the two required slots. The MS-MAC then sends the remainder of the TM-SDU in one 
MAC-FRAG PDU (264 bits of TM-SDU) and the MAC-END PDU (final 192 bits). The MS has no further 
signalling to send, so the MAC-END PDU does not contain the "reservation requirement" element, and the 
MAC block is completed with the Null PDU and fill bits. 

23.5.3 Cancel request 

The LLC may use the TMA-CANCEL request primitive to stop the MAC activities relating to a particular 
TMA-UNITDATA request. The "handle to the request" references the service request that is to be aborted. 

On reception of a TMA-CANCEL request primitive from the LLC, the MS-MAC shall cease all activities 
related to the service request as identified by its handle. The MS-MAC shall report to the LLC that MAC 
transmission activities have been aborted, indicating whether: 



a) the TM-SDU has not been completely sent; or 
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b) the complete TM-SDU has been sent at least once; 

using the TMA-REPORT indication primitive. 

NOTE 1 : This procedure can be used by the LLC to abort transmission of a message until: 

the complete TM-SDU, or final fragment of a fragmented TM-SDU, has been 
sent by reserved access or by stealing; or 

the complete TM-SDU has been sent and acknowledged by random access; 

after a first transmission of a random access message, the TMA-CANCEL 
request stops the MS-MAC from sending further random access retries. 
However, it should be noted that the BS may have received the message. 

NOTE 2: The primitive TMA-CANCEL request is used for modelling purposes only. 

23.5.4 Channel allocation 

23.5.4.1 Transmission of channel allocation 

The BS may send a channel allocation command either: 

a) to instruct an addressed MS (or MSs) to move from the current channel to another channel; or 

b) to allocate an additional channel for MSs that are capable of providing concurrent MAC services i.e. 
operating on multiple channels. 

The BS shall perform the allocation by including the "channel allocation" element in a MAC-RESOURCE 
or MAC-END PDU. The "channel allocation" element is an optional element, included only when required. 

The channel allocation is generally sent in a MAC-RESOURCE PDU. However, if the BS wishes to send 
channel allocation information with a fragmented message then that information shall be included within 
the MAC-END PDU and shall not be included within the MAC-RESOURCE PDU. 

For the MAC-RESOURCE PDU, the channel allocation shall refer to the MS or MSs addressed in the 
MAC header. For the MAC-END PDU, the channel allocation shall refer to the MS or MSs receiving the 
fragmented message, addressed in the MAC-RESOURCE PDU that contained the first fragment. 

The channel allocation command may be used to allocate a different channel (timeslot or timeslots) on the 
current RF carrier or to change both the carrier and timeslot(s) (see clause 21). 

When the BS directs the MS to an assigned channel, it shall set element "timeslot assigned" to indicate 
the appropriate timeslot(s), as a bit map. If the BS wishes the MS to return to a common control channel, 
i.e. MCCH or common SCCH, it shall set "timeslot assigned" = "OOCXV and indicate the main carrier 
number. 

The channel allocation command may be used to allocate a channel on the current cell. It may also be 
used to allocate a channel on another cell e.g. in case of announced cell re-selection type 1. The "cell 
change flag" shall indicate whether the channel allocation is for another cell. For a channel allocation 
directing an MS to another cell, the bit map in element "timeslot assigned" shall refer to the timeslot 
numbering on the new cell. 

NOTE 1 : The channel allocation method is used for directing addressed MSs to a specified 
channel. In addition, the broadcast message SYSINFO PDU (the content of BNCH) 
may cause an MS to move from one common control channel to another, e.g. when 
the number of common SCCHs is changed, (see subclause 23.3). For such a move, 
the same endpoint identifier applies, and the same service to the LLC is maintained for 
basic link and for any individual advanced link. 
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NOTE 2: When the BS assigns a channel for a circuit mode call, the resource allocation should 
correspond to that required for the network layer basic service information for the call, 
(see clause 14). For example, the number of slots per frame allocated by element 
"timeslot assigned" should match the basic service information. 

NOTE 3: It is optional for the MS to be capable of using a multi-slot channel, or of supporting 
concurrent channels on one carrier or of supporting concurrent multi-carrier operation. 
The BS should use the information on MS capabilities provided in the mobile class 
when allocating resources, i.e. the -class of MS" element, see clause 16. 

23.5.4.2 Reception of channel allocation 

The channel allocation element includes a two-bit element "allocation type", which is intended to aid 
interpretation of the allocation particularly by those MSs that are capable of concurrent operation. The 
precise procedures are defined in subclauses 23.5.4.2.1 and 23.5.4.2.2. 

The values for the "allocation type" are as follows: 

a) OO2: Replace current channel with specified channel; 

This indicates that the allocated channel is intended to replace the current channel (i.e. the channel 
on which the command was received). This replacement applies only to the channel on which the 
command was received, not to any other concurrent channels that the MS may be using on that 
carrier. If the current channel is a multi-slot channel, the replacement applies to all the timeslots 
comprising that channel. 

The "Replace 1 * mechanism may be used to move the MS to a different resource allocation. 
Otherwise it may be used if the BS wishes to increase or decrease the number of slots allocated to 
a particular assigned channel; the BS sends a "Replace" channel allocation on the assigned 
channel indicating the revised slot allocation. 

b) 01 2: Additional channel allocation; 

This indicates the allocation of an additional independent channel for an independent service e.g. a 
concurrent service. It cannot be used for changing the configuration of the current channel (see 
above). 

c) 1 0 2 : Quit current channel and go to specified channel; 

This allows the BS to replace the current channel but without maintaining full service. For example, 
any advanced links on the current channel are implicitly disconnected, and any current traffic 
transmit/receive authorisation does not apply on the new channel (see subclause 23.8.2). 

d) 11 2 : Replace current channel with specified channel, plus MCCH/SCCH or additional carrier 
specific signalling channel (CSS channel) in timeslot 1 ; 

This indicates that the specified channel is intended to replace the current channel i.e. the channel 
on which the command was received. If the specified carrier is the main carrier, it indicates that the 
MS may, if capable, use also the MCCH or the appropriate common SCCH for that MS. If the 
specified carrier is not the main carrier, it indicates that the MS may, if capable, use timeslot 1 as an 
additional channel to increase signalling capacity between the MS and BS. If the MS is not capable 
of receiving both the specified channel and the MCCH/SCCH or CSS channel then the specified 
channel shall take precedence. 

If the MS uses the CSS channel then it shall regard that channel as an independent single-slot 
channel. For the purposes of the general procedures for transmission and reception of signalling 
messages, the MS shall apply those procedures as if the CSS channel were an assigned channel, 
allocated by a specific MAC-RESOURCE PDU with "timeslot assigned" = "1000 2 ". i.e. allocation of 
timeslot 1 . However, reduced channel maintenance procedures shall apply on the CSS channel, 
and the CSS channel becomes invalid when the MS has no other assigned channel on that carrier 
(see subclause 23.5.6). 
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NOTE: For example, the BS might decide to allocate a CSS channel to provide information to 
MSs on that carrier about new calls, e.g. late entry signalling, without disturbing the 
operation of the assigned SCCHs and traffic channels on the other timeslots. The CSS 
channel could also be used for other signalling purposes such as status messages or 
packet data. 

The BS may allocate the CSS channel to all MSs using that carrier, by setting the 
"allocation type" to 11 2 in all the channel allocations. Slot 1 could also be an assigned 
channel for some MSs e.g. for advanced links with low data transfer throughput. The 
channel is then shared between the MSs. 

An MS in a circuit mode call may, for example, send the U-TX-DEMAND PDU on the 
CSS channel, e.g. with a high priority request. However, if FACCH is available on the 
assigned channel, then the MS should use this in preference to the CSS channel. 

If an MS has an advanced link on its assigned channel then it cannot send signalling 
related to that advanced link on the CSS channel. 

The procedures for reception of a channel allocation are described separately for individually and group 
addressed allocations. This is principally because the MS is required to obey an individually addressed 
channel allocation, whereas it may choose whether to obey a group addressed channel allocation. 

The following procedures indicate the service provided by the channel to the LLC. This applies principally 
to any advanced links, since signalling messages for concurrent advanced links for one address are 
discriminated only locally, by an endpoint identifier which corresponds to a particular MAC channel 
(timeslot or timeslots). The use of the TMA-RELEASE indication primitive for disconnecting an advanced 
link as defined in the following procedures, or if the MS leaves the channel as a result of channel 
maintenance procedures, should not occur except in case of transmission errors. The normal method of 
disconnection of an advanced link is by the LLC's AL-DISC PDU. 

The usage of the TMA-RELEASE indication primitive for implicit disconnection does not apply to CMCE 
calls, since a call identifier is included in CMCE signalling messages. For a group call, especially on a 
(quasi-)transmission trunked system, the MS may sometimes receive a channel allocation on the group 
address and sometimes on its individual address. 

23.5.4.2.1 Individual channel allocation 

On reception of a channel allocation for one of its individual addresses, i.e. its ISSI/ASSI, SMI or a 
corresponding event label, the MS-MAC shall perform the following procedure. 

a) If "allocation type" = 00 2 or 11 2 ("Replace" or "Replace + CSS channel") in the channel allocation 
element, the MS shall move from the current channel to the specified channel. It shall assume that 
the allocated channel will provide the same individual service to the LLC as the current channel, i.e. 
the channel on which the channel allocation was received, corresponding to the same endpoint 
identifier. 

If: 

the MS receives an individual "Replace" command for another carrier; and 
it is receiving other channels on the current carrier; and 

the MS is not capable of concurrent multi-carrier operation or if this is a cell change; 

then the MS-MAC shall issue a TMA-RELEASE indication primitive to the higher layers for each of 
the other channels so that any advanced links on those other channels are implicitly disconnected. 
Otherwise, if the MS is capable of continuing to receive its other channels, then those other 
channels are not affected. 

If "allocation type" = 1 1 2 and if the assigned carrier is the main carrier then the MS may, if capable, 
use also the MCCH or the appropriate common SCCH for that MS. If the assigned carrier is not the 
main carrier then the MS may, if capable, use slot 1 as a CSS channel. If the MS is not capable of 
receiving both the assigned channel and the common or CSS channel then the MS shall ignore the 
common/CSS allocation. 
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NOTE 1: For either "replace" command within the cell, the service provided to the LLC is 
maintained both for basic link and for any individual advanced link. For an allocation in 
another cell, any current advanced links will be released. (The MLE issues the 
TL-RELEASE request to the LLC). For either "replace" command received while the 
MS is in a circuit mode call, current traffic transmit and/or receive authorisation may 
apply also on the allocated channel; refer to subclause 23.8.2. 

NOTE 2: The "replace" command applies only to the channel on which the message was 
received, and so cannot be used to simultaneously replace other concurrent channels 
on that carrier when allocating a channel on another carrier. However, if the channel 
allocation PDU includes a slot grant on the current channel with "granting delay" > 
OOOO2 then the MS does not change channel immediately (see subclause 23.5.4.3). 
During the interim time, the MS should continue to receive its other concurrent 
channels, since the BS may also send the "replace" command on one of those 
channels, enabling both sen/ices to be maintained on the new carrier. Then, in the 
timing procedure for the carrier change, the MS may use the later (or latest) of the 
specified times. 

NOTE 3: When the MS receives a channel allocation on the MCCH or appropriate common 
SCCH allocating an assigned channel with "allocation type" = 00 2 , the MS is not 
permitted to continue to use the MCCH or common SCCH. 

b) If "allocation type" = 01 2 (Additional channel) in the "channel allocation" element then the MS shall 
obey the command to receive the allocated channel. If the MS is not already receiving the indicated 
channel then it shall allocate an endpoint identifier for the new channel. 

NOTE 4: A new endpoint identifier will usually be required. However, for example, in the case of 
independent allocation of uplink and downlink for concurrent calls involving the same 
MS, that MS may receive independent channel allocations with the same carrier 
number and same element "timeslot assigned" but with a different "Up/downlink 
assigned" element. 

If a TM-SDU was included within the PDU that allocated the channel then the TMA-UNITDATA 
indication primitive shall contain both the endpoint identifier of the channel on which the message 
was received and also the endpoint identifier of the allocated channel. 

NOTE 5: This enables the higher layers to make correct usage of the new channel. For 
example, for an AL-SETUP PDU for a new advanced link, sent with the additional 
channel allocation, the new advanced link is on the allocated channel. 

If the MS is not capable of receiving all concurrent channels as well as the newly allocated channel, 
then the MS-MAC shall issue a TMA-RELEASE indication primitive to the higher layers for those 
channels that it can no longer receive. Otherwise the MS shall continue to receive all concurrent 
channels, including the channel on which the command was received, as well as the newly 
allocated channel. 

c) If "allocation type" = 10 2 (Quit current channel) in the "channel allocation" element then the MS shall 
issue a TMA-RELEASE indication primitive for the current channel, to implicitly disconnect any 
individual advanced link, and shall cease to receive that channel. 

If the MS is already receiving the allocated channel then any advanced links on that channel are 
unaffected and the endpoint identifier is unchanged. 

If the channel allocation is a cell change or if it is allocating an assigned channel, i.e. "timeslot 
assigned" * 0000 2 , then the MS shall move to the indicated channel, issuing the TMA-RELEASE 
indication primitive for any concurrent channels that it is no longer capable of receiving. 

If the channel allocation is not a cell change and if it indicates common control channel, i.e. 
"timeslot assigned" = 0000 2 , and if the MS is receiving other assigned channels then the MS need 
not move to the common control channel. 

The MS-MAC shall inform the MLE about the channel now in use using the TMC-SELECT indication 
primitive. 
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23.5.4.2.2 Group-addressed channel allocation 

If the MS receives a channel allocation for one of its group addresses (or for a corresponding event label), 
the appropriate procedure i), ii) or iii) below shall apply. 

i) If the MS received the channel allocation on the MCCH or on a common SCCH, then the "allocation 
type" may be 00 2 (Replace) or 01 2 (Add) or 11 2 (Replace + CSS channel). 

If a TM-SDU was included within the PDU that allocated the channel then the MS-MAC shall set the 
"channel change response required" parameter to "true" in the TMA-UNITDATA indication primitive, 
to indicate that a response is required to instruct the MAC whether it should accept the allocation. 

If the higher layers return a TMC-CONFIGURE request primitive containing the "channel change 
accepted" parameter then the MS-MAC shall obey the channel allocation command. If "allocation 
type" = 1 1 2 and if the MS is not capable of receiving both the assigned channel and the common or 
CSS channel then the MS shall ignore the common/CSS allocation. 

If the MS was receiving other channels on the main carrier, and if it is not capable of receiving those 
other channels as well as the newly allocated channel, then the MS-MAC shall issue a 
TMA-RELEASE indication primitive to the higher layers for any channels that it can no longer 
receive. 

If the higher layers do not return a TMC-CONFIGURE request primitive then the MS-MAC should 
ignore the channel allocation. 

NOTE 1: It is optional for the MS to obey a group-addressed channel allocation. The MS-MAC 
refers to the higher layers because, for example, for a circuit mode call the MS-MAC 
should move to the channel only if the CMCE accepts the associated message. Also, 
the MS should not accept a group-addressed channel allocation if it would thereby fail 
to receive an ongoing individual signalling exchange, individual advanced link or 
individual circuit mode call on the current channel(s). It is recommended that the BS 
includes a higher layer message when it sends a group-addressed channel allocation, 
indicating the intended usage of the channel allocation. 

NOTE 2: If the MS accepts a channel allocation with "allocation type" = 00 2 , it is not permitted to 
continue to use the MCCH or common SCCH. 

ii) If the MS received the channel allocation on an assigned channel then the "allocation type" may be: 

a) 00 2 (Replace current channel), in which case the MS shall assume that the allocated channel 
will provide the current service for that group address; 

b) 01 2 (Additional channel), in which case the MS shall assume that the channel is intended for 
the purpose indicated in the higher layer message; 

c) 10 2 (Quit current channel), in which case the MS should assume that the current service for 
that group address is not fully maintained, e.g. current traffic transmit/receive authorisation 
does not apply; 

d) 11 2 (Replace current channel, and add CSS channel), in which case the MS shall assume 
that the allocated channel will provide the current service for that group address and that 
timeslot 1, or the MCCH or common SCCH, may be used for additional signalling. 

In case b), the MS-MAC shall set the "channel change response required" parameter in the 
TMA-UNITDATA indication primitive to "true" to indicate that a response is required to instruct the 
MAC whether it should accept the allocation. The procedure shall be as described in i) above. The 
MS may continue to receive the current channel. 

In case a), c) or d), the MS shall cease to receive the current channel, unless it has a concurrent 
independent allocation on that channel for an individual address. 
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If the channel allocation is for an assigned channel, the MS-MAC shall set the "channel 
change response required" parameter in the TMA-UNITDATA indication primitive to "true". If 
the higher layers return a TMC-CONFIGURE request containing "channel change accepted 1 * 
then the MS-MAC shall obey the channel allocation. If the higher layers do not accept the 
channel allocation then, if the MS does not have a concurrent assigned channel, it shall 
return to the main carrier. 

If the channel allocation is directing the MS to common control channel, i.e. "timeslot 
assigned" = 0000 2 , and if the MS does not have a concurrent assigned channel then the MS 
shall obey the command. If the MS has a concurrent assigned channel then it may obey the 
allocation as instructed by the higher layers. 

iii) If the MS received the channel allocation on CSS channel then the "allocation type" may take any of 
the four values. 

For allocation type 00 2 (Replace) or 01 2 (Add) or 1 1 2 (Replace + CSS channel), the MS shall decide 
whether to accept the channel allocation, following the same procedure as described in i) above. If 
the MS accepts the channel change, and if "allocation type" = 00 2 , the MS shall not continue to use 
the CSS channel. 

For allocation type 10 2 (Quit), the MS shall cease to receive the CSS channel. However, it may 
choose whether to move to the indicated channel. 

After a channel change, the MS-MAC shall inform the MLE about the channel now in use using the 
TMC-SELECT indication primitive. 

23.5.4.3 Channel change 

23.5.4.3.1 Timing of channel change 

When the MS-MAC obeys a channel allocation command, it shall inform the lower layers of any change of 
RF carrier and/or timeslot(s). The carrier information is contained in the "channel allocation" element. 
Refer to clause 21 . 

For a change of carrier within the cell, the MS shall assume that the current frame and slot 
synchronisation apply also on the new carrier. 

When directed to a new cell, the MS-MAC shall assume the frame and slot synchronisation from the 
SYNC and SYSINFO PDUs most recently received while scanning the main carrier of that cell (see 
subclause 23.7). On receiving the TMC-SELECT indication primitive for a cell change channel allocation, 
the MLE returns a TMC-SELECT response primitive indicating the main carrier of the new cell, enabling 
the MAC to reference the correct information. 

If a "slot granting" element is included in the same PDU as the channel allocation element then: 

if element "position of grant" in the PDU indicates "Current Channel", the MS shall obey the 
procedure for use of reserved slots (see subclause 23.5.2) on the current channel; 

otherwise the MS shall assume that the slot grant is on the allocated channel. 

The first uplink (respectively downlink) slot on the allocated channel shall be defined relative to either: 

a) the end of the downlink slot containing the channel allocation; or 

b) in the case of a channel allocation with a slot grant on the current channel (with "granting delay" * 
1111a): 

the end of the last uplink slot granted by that PDU (or the end of the slot containing a granted 
subslot); 
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c) if the current channel is a multi-slot channel, and the "allocation type" is not 01 2 , i.e. not "Add", and 
the next immediate uplink slot following the channel allocation is part of the current channel, and the 
MS is transmitting traffic in that slot or was previously granted that slot for reserved access: 

the end of that next immediate uplink slot; 

whichever is the later. Then, after one timeslot duration, the first uplink (respectively downlink) slot on the 
allocated channel shall be defined as the next uplink (respectively downlink) slot that corresponds to one 
of the timeslots indicated by element "timeslot assigned". This timing rule shall apply both for allocation 
within the same cell and for a different cell. 

For a slot grant on the allocated channel, granting delay = "0" in the "slot granting" element shall refer to 
the use of the first uplink slot on the allocated channel. Granting delay > "0" shall then refer to delaying by 
the specified number of opportunities for reserved access on the allocated channel as defined by element 
"timeslot assigned". 

NOTE 1 : Condition c) above applies only to a frequency full duplex MS. It assumes that the MS 
cannot stop transmission immediately and should not stop in the middle of a full slot. 
For example, if the MS is transmitting traffic and receives a channel allocation sent in 
downlink slot 1 , the MS should continue to transmit in the immediately following uplink 
slot 4 (if that is a valid traffic slot), before switching. 

NOTE 2: The following are examples of the channel timing, for allocation within the same cell. 

i) For a channel allocation sent in slot 1 , assigning timeslot 1 , e.g. on another RF 
carrier: 

the first uplink slot on the allocated channel is the uplink slot 1 of the 
same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 1 of the 
next TDMA frame. 

ii) For a channel allocation sent in slot 1 , assigning timeslot 2: 

the first uplink slot on the allocated channel is the uplink slot 2 of the 
same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 2 of the 
next TDMA frame. 

iii) For a channel allocation sent in slot 1, with a single subslot grant on the current 
channel in that TDMA frame, and assigning timeslot 2: 

the first downlink (respectively uplink) slot on the allocated channel is the 
downlink (respectively uplink) slot 2 of the next TDMA frame. 

iv) For a channel allocation sent in slot 1 , with a single subslot grant on the current 
channel in that TDMA frame, and assigning timeslot 3: 

the first uplink slot on the allocated channel is the uplink slot 3 of the 
same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 3 of the 
next TDMA frame. 
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v) For a channel allocation sent in slot 1 , with a single subslot grant on the current 
channel in that TDMA frame, and assigning timeslots 1 and 4: 

the first uplink slot on the allocated channel is the uplink slot 4 of the 
same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 1 of the 
next TDMA frame. 

vi) If a (frequency full duplex) MS is transmitting traffic on a multi-slot channel 
comprising timeslots 1 , 2 and 3, and receives a channel allocation sent in slot 2 
of a frame in the range 1-17, replacing the current channel with timeslots 2, 3 
and 4, then the MS continues to transmit traffic in uplink slot 1 before it switches 
channel. Then: 

the first uplink slot on the allocated channel is the uplink slot 3 of the 
same TDMA frame; 

the first downlink slot on the allocated channel is the downlink slot 2 of the 
next TDMA frame. 

For allocation on a different cell, the MS still allows one timeslot duration 
(approximately 14,17 ms). Then the first uplink (respectively downlink) slot on the 
allocated channel on the new cell is the next uplink (respectively downlink) slot that 
corresponds to one of the timeslots indicated by element "timeslot assigned" - using 
the new cell synchronisation. This timing applies whether the new cell is synchronised 
to the current cell or not. The normal rules for slot grants and CLCH permission then 
apply on the allocated channel. 

NOTE 3: Element "position of grant" is included to allow flexibility of channel scheduling by the 
BS. For example, if there is already traffic on the uplink of the allocated channel, the 
BS may wish to grant a subslot on the current channel for a layer 2 acknowledgement 
from an MS that is to receive traffic, e.g. in case of independent allocation of uplink 
and downlink. In other cases, granting on the allocated channel may often be more 
appropriate. 

23.5.4.3.2 Use of "timeslot assigned" 

If the "timeslot assigned** element * 0000 2f the MS-MAC shall note that the channel is an assigned 
channel, assigned for SCCH or for a circuit mode call. If the "timeslot assigned" element = 00002, the MS 
shall go to the appropriate common control channel as indicated by the last received SYSINFO PDU. 

An assigned channel may comprise one or more timeslots per TDMA frame, as indicated by the bit map in 
element "timeslot assigned". 

For "allocation type" = 11 2 (i.e. Replace + CSS channel), the "timeslot assigned" element shall indicate 
only those slots belonging to the assigned channel, so the first bit in the bit map shall be 0 (bit map = 
OXXX2). The use of slot 1 for the CSS channel is implicit. 

NOTE: The designation of whether the MS-MAC regards the channel as "assigned" or 
"common" affects the random access and channel maintenance procedures. If the BS 
assigns slot 1 of the main carrier for a circuit mode call, it should send a channel 
allocation command to those users. This does not cause a change of carrier or 
timeslot; but it is needed to change the MAC mode from "common" to "assigned", and 
also to define a monitoring pattern and a traffic usage marker. A similar procedure 
applies if the BS wishes to allow an MS that is receiving a CSS channel to use slot 1 of 
that carrier for a circuit mode call or as a fully assigned SCCH. 
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23.5.4.3.3 Use of "up/downlink assigned" 

The MS-MAC shall note, from element "Up/downlink assigned" whether either or both directions on the 
allocated channel have been assigned exclusively for the usage required by the MS. 

This information generally affects only the channel maintenance procedure. For example, in the case of 
independent allocation of uplink and downlink for different purposes, reduced procedures shall apply; see 
subclause 23.5.6. 

However, for the application of the general procedures for transmission and reception of signalling 
messages, each control channel (ACCH or SCCH) shall be assumed to occupy any control slots on both 
the downlink and uplink directions, as indicated by element "timeslot assigned". 

23.5.4.3.4 CLCH permission 

If the U CLCH permission" flag indicates "Immediate CLCH permission" then the MS may use the first 
subslot of the first uplink slot on the allocated channel for linearization, without needing to receive the 
corresponding ACCESS-ASSIGN PDU. 

Otherwise, if the MS requires to use CLCH for linearization, it shall wait for an ACCESS-ASSIGN PDU 
indicating a linearization subslot. 

NOTE: This flag is included to allow for fast call set-up with a change of RF carrier while still 
allowing flexibility for the BS, e.g. in cases of independent allocation of uplink and 
downlink or repeat set-up signalling for a group call. The BS should at least give CLCH 
permission to any MSs that need to use CLCH for linearization and that are granted 
slots and/or given transmit permission on a new carrier. The CLCH permission applies 
to any MS that obeys the channel allocation message, whether or not it has been 
granted slots and/or transmit permission. For "allocation type" = 11 2, the CLCH 
permission applies only to the assigned channel, not to the CSS channel. 

23.5.4.3.5 Monitoring pattern information 

The MS shall note the monitoring pattern information in case it is required to transmit user traffic on this 
channel. This requirement to store the monitoring pattern information applies to any MS that obeys the 
channel allocation message, whether or not it has been given permission to transmit user traffic at this 
time. 

The monitoring pattern information indicates in which downlink frames the MS is required to receive 
downlink slots and attempt to decode any signalling messages while it is transmitting traffic. This enables 
the BS to send signalling messages to that MS during its traffic transmission. 

NOTE 1 : See clause 9 for the definition of the usage of the monitoring pattern numbers. 

In the case that no monitoring pattern is assigned, an additional field defines the multiframes in which the 
MS shall monitor the assigned slot(s) in frame 18 within the capabilities of that MS (see subclauses 
23.3.1 .3 and 23.3.1 .4, and clause 21). 

The requirements for the MS to adhere to the assigned monitoring pattern is only within the capabilities of 
that MS. The BS should note those capabilities when assigning monitoring patterns and transmitting 
signalling messages to the MS. For example, for an MS that is not frequency full duplex, the BS should 
not assign a monitoring pattern for frames 1-17 when allocating a multi-slot channel; also, the MS may 
not receive all the assigned downlink slots in frame 18. 

NOTE 2: The monitoring pattern information refers to the requirements on an MS that is 
transmitting traffic to receive the downlink of the current channel. This is not the same 
as the "monitoring procedure" defined in subclause 23.7.4, in which the MS measures 
the signal strength of adjacent cells and calculates C2. 

NOTE 3: The BS designer should note that the assignment of all three monitoring patterns to a 
frequency half duplex MS in a simplex call may reduce that MS's ability to perform cell 
re-selection measurements on adjacent cells while it is transmitting traffic. 
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NOTE 4: For "allocation type" = 11 2, the monitoring pattern information applies only to the 
assigned channel, not to the CSS channel. 

23.5.5 Usage marker assignment 

A traffic usage marker is a 6-bit MAC label used during circuit mode calls for transmitter pre-emption, for 
prevention of crossed calls and for channel maintenance purposes. The BS shall assign a traffic usage 
marker before any traffic transmission takes place on an assigned channel. 

It shall assign the usage marker with a message that contains also a channel allocation command 
directing MS(s) to an assigned channel. The usage marker assignment shall be valid for that MS (or those 
MSs) only on that assigned channel. So, for example, for message trunking, one traffic usage marker 
generally applies for the complete call and the same usage marker should be assigned for all participants 
in that call on that assigned channel; whereas, for transmission trunking, the BS should assign a traffic 
usage marker for each "over". 

NOTE 1 : If the BS wishes to assign a traffic usage marker on an already assigned channel, then 
it may use the "replace channel" command indicating the current channel. 

NOTE 2: For "allocation type" = 1 1 2 , the usage marker applies only to the assigned channel, not 
to the CSS channel. 

When there is traffic (TCH or STCH) on either the uplink or the downlink, the BS shall use the appropriate 
traffic usage marker in the ACCESS-ASSIGN PDU sent on the AACH in frames 1 - 17 on the downlink 
assigned channel to confirm permission to transmit and/or receive traffic. For uplink traffic, Header 11 2 
shall be used, with "Field 2" set to the uplink traffic usage marker. For downlink traffic, Header 01 2 , 10 2 or 
1 1 2 shall be used, with "Field 1 " set to the downlink traffic usage marker. 

A traffic usage marker may also be sent in the ACCESS-ASSIGN PDU in frame 18, though frame 18 is 
never used for TCH or STCH. Then the frame 18 Header shall be set to 11 2 and the usage marker in 
"Field 1" may be set to either the uplink or downlink traffic usage marker as appropriate. This can be 
useful for channel maintenance purposes or, during uplink traffic, if the BS has not assigned a monitoring 
pattern for frames 1-17. 

The procedures for channel maintenance by the MS-MAC, and the criteria for MS transmission and 
reception of traffic, are described in subclauses 23.5.6. and 23.8.2. respectively. 

When the BS wishes to assign an traffic usage marker, it shall use the MAC-RESOURCE PDU, which 
shall contain "Address Type" = HQ2 and the assigned traffic usage marker. The "channel allocation" 
element shall be included in that MAC-RESOURCE PDU or in the associated MAC-END PDU. If the 
MS-MAC receives a usage marker assignment without the corresponding channel allocation, e.g. in the 
case of fragmentation if the MS does not receive the MAC-END PDU, or if it does not obey the channel 
allocation then it shall ignore the usage marker assignment. 

A traffic usage marker shall apply for the direction(s) specified in the channel allocation, i.e. the 
appropriate direction for element "Up/downlink Assigned" = 01 2 or 10 2 , or both directions for element 
"Up/downlink Assigned" = 11 2 . If the BS uses independent allocation of the uplink and downlink for two 
circuit mode calls then the traffic usage marker should be different for the two directions. 

In the case of independent allocation of the uplink and downlink of a channel for concurrent calls involving 
the same MS, the MS-MAC may receive independent channel allocations of uplink and downlink, each 
with a usage marker assignment. Each usage marker shall apply independently for the specified direction. 
However, the same endpoint identifier applies for both allocations when the allocations are for the same 
assigned channel. 



Page 492 

ETS 300 392-2: March 1996 

The MS-MAC shall consider that an assigned traffic usage marker is valid until: 

i) it leaves the assigned channel (or returns to common mode on this channel); or 

ii) it receives another traffic usage marker with a channel allocation for the same direction(s) or for 
both directions on the same assigned channel; or 

iii) it receives a channel allocation for the same direction(s) or for both directions on the same 
assigned channel, but without a usage marker assignment. 

The BS is responsible for deciding when a traffic usage marker may safely be re-used for a subsequent 
call on the same physical channel 

23.5.6 Maintenance of assigned channel 

The MS shall receive the MCCH, or the appropriate common SCCH, unless directed by the BS to an 
assigned channel. An assigned channel may be intended for secondary control purposes or for a circuit 
mode call. The MS shall assume that the assigned channel is intended for secondary control unless it has 
received a traffic usage marker for use on the channel. 

The ACCH is the control channel associated with an assigned traffic channel. When ACCH is present, its 
usage is similar to the usage of assigned SCCH, and there is no distinction in the pre-set usage marker 
designation in the AACH. Both types of control channel shall be regarded as assigned control channel. 
The traffic usage marker is generally used only while the channel is carrying user traffic TCH or STCH. 

The procedures for channel maintenance defined in subclause 23.5.6.1 apply on either type of assigned 
channel, unless specified otherwise. 

The procedures for maintenance of a CSS channel are reduced compared with those for a normal 
assigned channel. They are defined in subclause 23.5.6.2. 

23.5.6.1 Criteria for leaving assigned channel 

The MS-MAC shall continue to receive and attempt to decode signalling on the downlink assigned channel 
as defined by element "timeslot assigned", and within the constraints of the cell re-selection procedures 
and monitoring pattern requirements, until one of the following occurs: 

the MS-MAC obeys a channel allocation command from the BS, directing it elsewhere (see 
subclause 23.5.4); or 

the MS is required to leave the channel by one of the channel maintenance procedures in 
subclauses 23.5.6.1 .1 and 23.5.6.1 .2 below; or 

the MS-MAC receives a TMC-SELECT request primitive from the higher layers instructing it to 
leave the assigned channel; or 

the MS-MAC receives a TMC-CONFIGURE request primitive from the higher layers indicating call 
release for this channel, e.g. the user wishes to leave a group call. 

In the last case, the MS should not leave the channel if it has been assigned both directions of the channel 
in two independent allocations of uplink and downlink, and if the service on the other direction is still 
ongoing. 

23.5.6.1 .1 Checking of AACH 

The MS shall attempt to decode the AACH in slots appropriate to the downlink assigned channel within 
the constraints of the cell re-selection procedures and monitoring pattern requirements. 

If N.208 successive ACCESS-ASSIGN PDUs received in frames 1-17 in the AACH of slots appropriate to 
the downlink assigned channel indicate that: 

a) the downlink is unallocated, i.e. Header * OO2 and downlink usage marker = UMx (OOOOOO2); or 
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b) the channel has returned to exclusively common control use, i.e. Header = OQ2; or 

c) the relevant direction(s) have been assigned for another purpose (see below); 

then the MS shall regard the assigned channel as no longer valid for transmission or reception. Then, if 
the MS does not have a concurrent assigned channel, it shall return to the main carrier, i.e. to the 
appropriate MCCH or common SCCH. The MS-MAC shall inform the higher layers of the de-allocation 
using the TMA-RELEASE indication primitive and of any change of channel using the TMC-SELECT 
indication primitive. 

For criterion c) t the MS shall check as follows. 

If the downlink was assigned for this MS (element "Up/downlink Assigned" = 01 or 1 1), the MS shall 
regard the assigned channel as no longer valid if: 

for assigned SCCH: 

the downlink is not in assigned control i.e. the channel is no longer valid if Header = 00 2 or if 
the downlink usage marker * 000001 2 ; 

for a circuit mode call: 

the downlink is not in assigned control nor in traffic with the MS's usage marker i.e. the 
channel is no longer valid if Header = OO2 or if the downlink usage marker is neither 000001 2 
nor the MS's downlink traffic usage marker. 

If the uplink was assigned for this MS (element "Up/downlink Assigned" = 10 2 or 1 1 2 ), the MS shall 
regard the assigned channel as no longer valid if: 

for assigned SCCH: 

the uplink is unallocated or is being used for traffic i.e. the channel is no longer valid if 
Header = 11 2 and the uplink usage marker = 000000 2 or is > 0001 00 2 ; 

for a circuit mode call: 

the uplink is unallocated or is being used for traffic by other users i.e. the channel is no longer 
valid if Header = 11 2 and the uplink usage marker = 000000 2 or is > 0001 00 2 and is not the 
MS's uplink traffic usage marker. 

If the MS has been assigned both directions of the channel in two independent channel allocations then it 
shall not leave the channel on criterion c) unless both directions are no longer valid according to the above 
definition. 

NOTE 1: 



NOTE 2: 



NOTE 3: 



NOTE 4: 



The MS should not react to reception of only one adverse ACCESS-ASSIGN PDU, 
because of the possibility of incorrectly decoding the AACH. So N.208 > 2. 

For this procedure, the MS checks only the designation of slots belonging to the 
downlink assigned channel, although, in the case of an extended random access 
channel, the MS may be decoding other ACCESS-ASSIGN PDUs. 

As a result of de-allocation on criterion b) or c), the MS may actually remain on the 
same physical channel. However, its designation has changed from "assigned" to 
"common". 

If the BS has assigned only the uplink for a circuit mode call, and the downlink is not 
used for another purpose, the BS should mark the downlink as "assigned control" in 
the AACH, not "unallocated". Similarly, the BS should not use Header 00 2 unless the 
channel is entirely dedicated to common control usage. 
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23.5.6.1 .2 Inactivity time-out 

If the MS is on a channel assigned for SCCH, and a time T.208 elapses without either: 
transmission by the MS by reserved access; or 

receipt of a downlink message on this channel containing one of its addresses or event labels other 
than the predefined broadcast group address (all ones); 

then the MS shall regard the channel as no longer valid for transmission or reception. 

If the MS is on a channel assigned for a circuit mode call, and a time T.209 elapses without either: 

transmission by the MS, for traffic (TCH or STCH) or by reserved access; or 

receipt of a downlink message on this channel containing one of its addresses or event labels other 
than the predefined broadcast group address (all ones); or 

receipt of an ACCESS-ASSIGN PDU containing the MS's traffic usage marker either as the 
downlink or the uplink usage marker in the ACCESS-ASSIGN PDU, and in any frame 1 to 18; 

then the MS shall regard the channel as no longer valid for transmission or reception. 

In case of time-out on either T.208 or T.209 then, if the MS does not have a concurrent assigned channel, 
it shall return to the main carrier, i.e. to the appropriate MCCH or common SCCH. The MS-MAC shall 
inform the higher layers of the de-allocation using the TMA-RELEASE indication primitive and of any 
change of channel using the TMC-S ELECT indication primitive. 

NOTE: In order to keep MSs on the channel during long periods of FACCH, e.g. for an open 
channel, the BS may send occasional slots in frames 1-17 containing the traffic usage 
marker as the uplink usage marker (with Header 11 2 ); or it may use the traffic usage 
marker as the usage marker in frame 18 (frame 18 Header 11 2 ). Also, use of the traffic 
usage marker as the downlink usage marker in occasional slots in frames 1-17 (with 
STCH + STCH) is not precluded. Otherwise the BS could send dummy messages 
addressed to the MS(s) on the channel. 

23.5.6.2 Criteria for leaving carrier specific signalling channel 

After assignment of a CSS channel, the MS-MAC may continue to use that channel until one of the 
following occurs: 

it obeys a channel allocation command on that channel, directing it elsewhere (see 
subclause 23.5.4); or 

it has no other assigned channel on that carrier assigned either for SCCH or for a circuit mode call. 

The MS-MAC should inform the higher layers of the de-allocation of the CSS channel and of any change 
of channel. 

23.5.6.3 Traffic on downlink for other users 

When the MS is receiving an assigned channel, the downlink may be used for traffic independently of any 
usage of the uplink for signalling or traffic. For example: 

SCCH, but with downlink not dedicated to SCCH; 

inter-site message trunked circuit mode call. 

An MS is specifically instructed when it may process received user traffic TCH for transfer to its U-plane 
application as described in subclause 23.8.2. 

An MS that has not received such authorisation shall interpret the downlink slots as follows. 
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The MS shall assume that the downlink is in traffic mode carrying traffic for other MSs if the last AACH 
received in frames 1 - 17 in a slot appropriate to the downlink assigned channel contained a downlink 
traffic usage marker (i.e. Header * 00 2 and downlink usage marker > 0001 00 2 ). Otherwise it shall assume 
that the downlink is in signalling mode. (See clause 19 for the configuration in signalling and traffic mode). 

In both signalling and traffic mode, full (SF=0) or half slot (SF=1) downlink transmissions may be used. 
The slot flag (SF) shall correspond to a change between two training sequences, as described in clause 9. 

In the case of signalling mode: 

a) the MS shall interpret slots with SF = 0 as SCH/F; 

b) the MS shall interpret slots with SF = 1 as SCH/HD + SCH/HD. 
In the case of traffic mode: 

a) the MS shall interpret slots with SF = 0 as TCH, and shall ignore that TCH; 

b) for SF = 1, the MS shall interpret the slot as STCH + TCH or STCH + STCH, depending on the 
content of the first STCH. 

For STCH, the MS shall inspect the MAC header of each PDU in order to: 

discover whether the second half slot is stolen; 

perform PDU dissociation (in the case of C-plane stealing); 

process any C-plane messages addressed to itself. 

See subclause 23.8.4.2 for the method for reception of STCH. 

The MS shall ignore the TM-SDU in any MAC-U-SIGNAL PDUs, and the TCH. 

Slots containing the synchronisation training sequence shall always be interpreted as BSCH + SCH/HD. 

Traffic mode applies only to frames 1-17. Both MS and BS shall always be in signalling mode on 
frame 18. 

NOTE 1: The above procedure applies to any MS that does not have authorisation or "N.213 
permission" (see subclause 23.8.2.3.2) to receive TCH with this traffic usage marker. 
This includes an MS that is transmitting traffic in simplex mode, or an MS with a 
different traffic usage marker, or an MS on assigned SCCH. 

NOTE 2: When the BS changes the designation of the downlink channel, it may choose to send 
a few slots using the half-slot training sequence, to allow for poor reception of AACH. 
MS interpretation of SCH/HD and two-half-slot STCH is very similar. At other times, 
use of SCH/F (with PDU association) is recommended for most C-plane signalling on 
the downlink, since it is generally more flexible. 

23.6 PDU transfer for broadcast messages (TMB-SAP) 

23.6.1 Broadcast channels 

The BS shall transmit broadcast system information using the SYNC PDU transmitted on the BSCH and 
the SYSINFO PDU transmitted on the BNCH. 

NOTE: The ACCESS-DEFINE PDU also contains broadcast information relating to random 
access and is described within subclause 23.5.1 . 

On a traffic or CP channel, the BSCH and BNCH shall be transmitted in frame 18. The BNCH may also be 
transmitted during frames 1-17 of a control channel and both BNCH and BSCH may be transmitted on 
unallocated channels. The precise rules for BNCH and BSCH transmission are described in clause 9. 
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BNCH and BSCH shall be received and decoded by all MSs camped on a cell. These broadcast PDUs 
contain essential system information required by the MS to synchronise with and use the facilities of the 
system. An MS, on receiving and correctly decoding broadcast information shall remove the MAC header 
and shall store the parameters contained therein as the serving cell broadcast parameters. While 
scanning adjacent cells, the MAC may also be required to store the broadcast parameters for those 
adjacent cells for use in the cell re-selection procedures. The MAC shall then pass the TM-SDU to the 
MLE. Upon receiving subsequent BNCH or BSCH PDUs, the MAC shall update its stored serving cell 
parameters before passing the MLE data contained in the TM-SDU to the LLC which shall then be passed 
transparently to the MLE. The appropriate MAC primitives are TMB-SYNC indication and TMB-SYSINFO 
indication. 

The broadcast information in both of these PDUs relates to the system configuration for that cell. 
Therefore, the BSCH and BNCH contents transmitted on all carriers belonging to a single cell shall be 
identical. This means that the MS may receive the system information on any carrier belonging to a cell. 
This includes slot, frame and multiframe number implying that all carriers belonging to a BS shall be 
synchronised in time. 

23.6.2 Acquiring cell synchronisation 

An MS shall synchronise with a cell by first attempting to synchronise with the synchronisation training 
sequence contained in the SYNC burst (BSCH). On acquiring synchronisation, the MS shall then decode 
the contents of the SYNC PDU also contained in the synchronisation burst. The SYNC PDU shall contain 
the colour code, which shall be used by the MS to de-scramble the contents of all other bursts transmitted 
by that BS, and the system code, which shall indicate whether the system is a TETRA V+D or PDO 
system. The SYNC PDU shall also contain the slot, frame and multiframe number for this downlink slot 
giving the MS full synchronisation with this BS. The SYNC PDU shall also contain some information about 
the discontinuous mode of operation of the system. 

The MS may acquire cell synchronisation on any downlink carrier being transmitted by the BS for that cell. 
The BSCH information shall be the same for all carriers within a cell and the slot, frame and multiframe 
synchronisation shall be the same. 

Having synchronised with a cell, the MS shall continue to decode subsequent SYNC PDUs transmitted by 
that BS but shall only use those with the correct colour code to prevent an MS using the BSCH transmitted 
by an adjacent cell. 

NOTE: There is no co-channel interference protection on the BSCH. 

The MS shall store the information received in the SYNC PDU and shall update this stored information on 
receiving subsequent SYNC PDUs. 

23.6.3 Acquiring network information 

An MS, having acquired cell synchronisation by receiving and decoding the BSCH information, is able to 
decode all downlink bursts transmitted by the BS. First of all, the MS shall search for the BNCH in order to 
receive and decode the SYSINFO PDU containing system information for this cell. The SYSINFO PDU 
contains information about the frequency of the main carrier, the number of secondary control channels in 
operation on the main carrier, information used for power control and cell (re-)selection and some random 
access parameters (see clause 21 for full description). The MAC shall decode the SYSINFO PDU and 
store the MAC parameters. On receiving subsequent SYSINFO PDUs, the MAC shall update these stored 
parameters accordingly. 

Having decoded the SYNC and SYSINFO PDUs, the MS may locate the location of the MCCH, slot 1 of 
the main carrier, or the relevant common SCCH. The MS has all of the information needed to 
communicate with the system and may now receive downlink PDUs and transmit uplink PDUs using the 
procedures defined elsewhere within the MAC protocol. 
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23.7 Layer management communication (TMC-SAP) 
23.7.1 Path loss calculation 

The MAC layer makes signal strength measurements both autonomously on the serving ceil and under 
the control of the MLE layer on selected neighbouring cells. The signal strength measurements shall be 
passed to the MLE as an approximation of radio path loss using the path loss parameters, C1 and C2, 
which are defined in the following subclauses. 

23.7.1 .1 Path loss parameter C1 

The MS shall calculate the path loss parameter, C1 , according to the following formula: 

C1 = RSSI - RXLEV_ACCESS_MIN - Max ( 0, MS_TXPWR_MAX_CELL - P MS ) (80) 

where: 

RSSI = averaged received signal level at MS or equivalent signal quality measurement; 
RXLEV_ACCESS_MIN = minimum permissible received level at MS in this cell; 
MS_TXPWR_MAX_CELL = maximum MS transmit power permissible in this cell; 
P MS = maximum transmit power of the MS. 
C1 is expressed in dB, all the other parameters in dBm. 

C1 is calculated for the serving cell and for adjacent cells by scanning. RSSI, therefore, is defined in the 
relevant subclauses for serving cell measurement (see subclause 23.7.3) and scanning (see 
subclause 23.7.5). 

The cell selection parameters, RXLEV_ACCESS_MIN and MS_TXPWR_MAX_CELL, shall be transmitted 
on all cells using the Broadcast Network Channel (BNCH) and shall be decoded by the MS for C1 
calculation. 

After synchronisation has been acquired, the serving cell measurement procedure requires that C1 shall 
be calculated using the cell selection parameters transmitted on the serving cell. The scanning procedures 
also require a calculation of C1 on adjacent cells; in this case, the MS shall be synchronised to the 
adjacent cell and shall use the cell selection parameters transmitted on that adjacent cell in the above C1 
calculation. 

23.7.1 .2 Path loss parameter C2 

The MS shall calculate the path loss parameter, C2, according to the following formula: 

C2(n) = RSSI(n) - RXLEV_ACCESS_MIN_MCELL(n) - Max ( 0, MS_TXPWR_MAX_MCELL(n) - P MS )(81) 

where: 

RSSI(n) = averaged received signal level at MS or equivalent signal quality measurement; 

RXLEV_ACCESS_MIN_MCELL(n) = minimum permissible received level at MS; 

MS_TXPWR_MAX_MCELL(n) = maximum MS transmit power allowed in the cell; 

P MS = maximum transmit power of the MS. 

C2 is expressed in dB and all the other parameters in dBm. (n) indicates the n m adjacent cell carrier. 

C2 is calculated for adjacent cells by monitoring. RSSI, therefore, is defined in the relevant subclause for 
monitoring (see subclause 23.7.4). 
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The parameters, RXLEV_ACCESS_MIN_MCELL(n) and MSJTXPWR_MAX_MCELL(n), which are the 
cell selection parameters for the adjacent cells, shall be transmitted in the serving cell using an MLE 
broadcast message on the relevant common control channel (main and/or secondary). 

In the case where these parameters are not known by the serving cell or where the MS has not received 
them on the serving cell, the MS shall use the cell selection parameters for the serving cell as default 
values. These are broadcast on the serving cell BNCH. 



23.7.2 Cell selection 



The MLE may instruct the MAC to select a cell, as shown in figure 146, using the TMC-SELECT request 
primitive which shall contain a channel number parameter corresponding to a frequency. The MAC shall 
then instruct the physical layer to tune to that frequency for reception. As soon as the MS MAC has 
acquired synchronisation on that carrier and decoded the BSCH and BNCH for that cell, it shall confirm 
the cell selection, by sending a TMC-SELECT confirm primitive to the MLE, and begin the serving cell 
measurements described in the following subclause. If the TMC-SELECT request is to inform the MAC of 
a change to a cell which the MAC has previously been scanning, the MS MAC may already have acquired 
synchronisation on the new cell and decoded the BNCH and BSCH contents, in which case it may 
respond with TMC-SELECT confirm as soon as the physical layer has changed frequency. 



TMC-SELECT TMC-SELECT 
request confirm 



MS-MAC £ 



BS-MAC 



Figure 146: Cell selection 



This procedure is identical in the MAC for initial cell selection and cell re-selection. 



23.7.3 



Serving cell measurement 



Having selected and acquired synchronisation on a cell as described in the previous subclause, the MAC 
shall begin measurement of the serving cell downlink RSSI, as defined in the following subclause, and use 
this to calculate C1 for the serving cell (see subclause 23.7.1 .1). It shatl then periodically report C1 to the 
MLE using a TMC-MEASUREMENT indication primitive as illustrated in figure 147. This measurement of 
the serving cell downlink RSSI and calculation of C1 is known as surveillance and shall be based upon the 
cell selection parameters decoded on the serving cell. 



TMC-SELECT 
request 



TMC-SELECT 
confirm 

TMC-MEASUREMENT 
indication 



SYNC PDU 



MS-MAC 



SYSINFO PDU 



TMB-SYNC 
request 



2sk ^ 



TMB-SYSINFO 
request 



BS-MAC 



Figure 147: Cell selection and surveillance scenario 



23.7.3.1 Downlink measurements 



The MAC shall continuously perform the measurements described in this subclause on the physical 
channel(s) to which the MS is attached on the serving cell. Measurements shall be made on all downlink 
timeslots which the MAC is able to monitor within the constraints of its energy economy mode or 
according to the monitoring pattern for transmission on an assigned channel. 
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The MAC shall measure the received RF signal strength or make an equivalent signal quality 
measurement and calculate a running average of at least 5 measurement samples. 

These samples shall be taken during at least the last 5 seconds and at most the last 60 seconds. If less 
than 5 measurements were collected during this period, for example due to the constraints of an energy 
economy mode, then the last 5 measurements may be used. The measurement sample duration shall be 
at least SD1 (see clause 10). If the BS operates in MCCH sharing, the measurements shall be performed 
only on the frames reserved for the BS, and not on the common frames (see clause 9). Based upon these 
measurements, the path loss parameter C1 shall be calculated by the MAC at least every 5 seconds for 
the serving cell. 

The quality of the radio downlink shall be estimated from the success rate of decoding the AACH for a MS 
in idle mode. The MAC shall perform the following measurements to ensure the path loss to the serving 
cell is acceptable. The criterion for relinquishing the radio downlink is based on the Radio Downlink 
Counter (RDC). When the MAC first acquires cell synchronisation and begins to monitor the downlink of a 
common control channel, RDC shall be initialised to a value equal to RADIO_DOWNLINK_TIMEOUT. The 
RADIO_DOWNLINK_TIMEOUT parameter is broadcast on the BNCH. 

If the MAC is unable to decode an AACH message, RDC shall be decreased by N * N.210. (N.210 is a 
constant which defines the quality threshold for the MS). In the case of a successful reception of an AACH 
message, RDC shall be increased by N but shall not be increased above the value of 
RADIO_DOWNLINK_TIMEOUT. 

The parameter N is equal to the number of timeslots between successive downlink slots which the MS is 
attempting to receive and decode; therefore, N is dependent on the MS mode of operation. Some 
examples are listed below. 

a) MS in normal mode 

In this mode, the MS is monitoring the MCCH or a common SCCH and so listens to one slot per 
TDMA frame. Therefore, in this case, N=4. 

b) MS in an energy economy mode 

In this mode, the MS is not monitoring all downlink slots of the common control channel. For 
example, an MS operating with an energy group, EG5, may only be decoding one downlink slot per 
multiframe. In this case, N=72. 

c) MS receiving on an assigned channel 

In this mode, the MS is receiving one or more timeslots per TDMA frame depending upon the 
number of slots assigned to that channel. In this case, N = 4/number of timeslots per TDMA frame 
assigned to that channel on the downlink. 

d) MS transmitting on an assigned channel 

In this mode, the MS is transmitting on the uplink and monitoring the downlink according to the 
monitoring pattern given at channel assignment. In this case, N = 12/number of monitoring patterns 
allocated to the MS. This applies when 1 , 2 or 3 monitoring patterns are assigned. 

When the mode of operation of the MS is changed, the corresponding value of N shall be calculated by 
the MAC and used for updating RDC. RDC is valid for the cell, whatever the RF channel on which the MS 
decodes the AACH. 

Radio downlink failure shall be declared when the RDC falls below 0. If this happens, the MAC shall 
inform the MLE that radio downlink failure has occurred using TMC-REPORT indication. 

NOTE: N.210 controls the AACH message error rate threshold at which radio downlink failure 
occurs. For example, if N.210 = 4 ( the ratio 4 to 1 between failure and success 
counting gives a decreasing RDC when the message error rate exceeds 20%. 
Therefore, a continuing message error rate greater than 20% will cause radio 
downlink time-out in this case. 
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23.7.3.2 Uplink measurements 



The criterion for determining the relinquishment of the radio uplink in the BS may be based upon uplink 
received signal strength measurement or an equivalent signal quality measurement and a measurement 
of the path delay from MS to BS derived from the time at which uplink slots are received at the BS. 

The measurement of uplink received signal strength or quality may be used by the BS as a criterion to 
relinquish the radio link. The BS may inform the MS if this happens by sending a MAC-RESOURCE PDU 
which includes the optional Power control element with a value set to "Radio uplink failure". On receiving 
this, the MS MAC shall inform the MLE using a TMC-REPORT indication in order to initiate the MLE cell 
re-selection procedures. 

The measurement of uplink path delay may also be used by the BS as a criterion to relinquish the radio 
link. This allows the BS to limit the MS-BS distance and prevent the MS grossly exceeding the planned 
ceil boundaries. The BS may inform the MS if this happens by sending a MAC-RESOURCE PDU which 
includes the optional Power control element with a value set to "Maximum path delay exceeded". On 
receiving this, the MS MAC shall inform the MLE using a TMC-REPORT indication in order to initiate the 
MLE cell re-selection procedures. 



23.7.4 



Monitoring 



Monitoring is an MS function which measures the signal strength of the adjacent cells and calculates C2. 
The cell selection parameters for the adjacent cell are broadcast on the serving cell for the C2 calculation. 
It is used when the MS is not synchronised to the adjacent cells and so cannot decode the adjacent cell 
BNCH. 

The following subclause describes the monitoring procedure. The MS MAC shall perform the 
measurements and fulfil the requirements of providing the C2 parameter to the MLE in a way which is 
equivalent to or better than the method described. 



23.7.4.1 



Monitoring scenario 



Figure 148 illustrates how the MLE initiates the monitoring procedure in the MAC by sending TMC- 
MONITOR-LIST request along with a list of channel numbers which correspond to the frequencies of the 
adjacent cell carriers to be monitored. 



TMC-MONITOR-LIST 
request 



TMC-MONITOR 
indication (C2) 
(TMC-SCAN-REPORT 
indication (C1) ) 



MS-MAC 



RSSI 



BS-MAC 



Figure 148: Monitoring scenario 

The result of the TM-MONITOR-LIST request shall be contained in the TMC-MONITOR indication. The 
MAC shall make the measurements needed to calculate C2 for each adjacent cell channel and shall 
periodically pass the result for each one using TMC-MONITOR indication. The MS shall use the adjacent 
cell parameters broadcast on the serving cell for the C2 calculation. If the MS has not received these, the 
MS shall use the cell selection parameters of the serving cell to calculate C2 instead. 

If the MS has already acquired synchronisation on an adjacent cell and it has decoded the broadcast 
parameters needed to calculate C1 , the MAC shall report the updated value of C1 for the adjacent cell 
using the TMC-SCAN-REPORT indication instead of reporting C2 for that cell. 

A TMC-MONITOR-LIST request with an empty channel list shall inform the MAC to cease adjacent cell 
monitoring. 
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23.7.4.2 Monitoring measurements 

The MAC shall measure the received RF signal strength or equivalent signal quality for all channels of the 
monitor list. 

As far as possible the same number of measurement samples shall be taken for all channels and the 
measurement samples shall be uniformly distributed over the averaging period. 

The MAC shall measure the received RF signal strength or make an equivalent signal quality 
measurement for all channels of the monitor list. For each channel, it shall calculate a running average of 
at least 5 measurement samples. These samples shall be taken during at least the last 5 seconds and at 
most the last 60 seconds. If less than 5 measurements were collected during this period, for example due 
to the constraints of an energy economy mode, then the last 5 measurements may be used. The 
measurement sample duration shall be at least SD1 (refer to clause 10). Using the average of these 
measurements, the MAC shall calculate the parameter C2 at least every 5 seconds. The MAC may in 
addition calculate the parameter C1 for all channels of the monitoring list with which it has already 
synchronised and decoded the BNCH. 

23.7.4.3 Signal strength measurement 

The RSSI measurements or equivalent signal quality measurements shall be made during the 
non-assigned or non-used timeslots of the physical channel(s) to which the MS is attached. 

NOTE: For example, for a receiving or idle MS, during the uplink slots of the physical channel, 
for a transmitting MS, during the downlink slots not already assigned to serving cell 
monitoring as defined by the monitoring pattern(s) allocated to the MS, for an MS in full 
duplex during the unused uplink slot of the control frame. 

The measurements shall be made whenever possible, taking into account the mode of operation and the 
frequency switching capability of the MS. However, the overall frequency of measurement, taking into 
account all channels, need not exceed the following rate: 

MS in half duplex RX or TX mode: 6 measurements per multiframe period; 

MS in idle mode: 1 measurement per 3 downlink slots of the MCCH or common 

SCCH. 

If the channel does not operate in timesharing mode, the measurement sample duration shall be at least 
SD2 as defined in clause 10. 

If the channel operates in timesharing mode and if the MS has knowledge of the timesharing 
synchronisation, the MS shall perform the measurements only during the timeslots exclusively reserved to 
the monitored channel. If no active timeslots can be found that coincide with the monitoring periods, the 
measurement shall not be performed on this channel. If some can be found, the measurement sample 
duration shall be at least SD1 . 

If the channel operates in timesharing mode and if the MS does not have knowledge of the timesharing 
synchronisation, the measurement sample duration shall be at least SD1 and several measurements are 
allowed on the same channel during one monitoring period. The MS shall calculate the average of the 5 
samples showing the highest RF signal strength during the preceding 10 seconds, these samples being 
separated by at least 50 ms. 

23.7.5 Scanning 

Scanning is an MS function which measures the signal strength of the adjacent cells and calculates C1 
using the adjacent cell parameters broadcast on the relevant adjacent cell. It is used when the MS is 
synchronised to the adjacent cell and is able to decode the adjacent cell BNCH and BSCH. 

The following subclause describes the scanning procedure. The MS MAC shall perform the 
measurements and fulfil the requirements of providing the C1 parameter to the MLE in a way which is 
equivalent to or better than the method described. 
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23.7.5.1 Scanning scenario 



Figure 149 illustrates how the MLE initiates the scanning procedure in the MAC by sending TMC-SCAN 
request along with a channel number which corresponds to the frequency of the adjacent cell carrier to be 
scanned and a scanning measurement method to indicate whether foreground, background or interrupted 
scanning is to be used. 

The MAC shall make the measurements needed to calculate C1 for the adjacent cell channel and shall 
pass the result using TMC-SCAN confirm. The MS shall use the cell selection parameters broadcast on 
the adjacent cell for the C1 calculation. 



TMC-SCAN 
request 



TMC-SCAN 
confirm (C1) 



MS-MAC 



SYNC PDU 



TMB-SYNC TMB-SYSINFO 
request request 



SYSINFO PDU 



BS-MAC 



Figure 149: Scanning scenario 



23.7.5.2 Scanning measurement 

Scanning shall comprise of achieving synchronisation with an adjacent cell, measuring the received signal 
strength or an equivalent signal quality and decoding the BNCH and BSCH broadcast on the adjacent cell. 
Scanning shall be performed on one channel at a time. Three different methods of scanning are defined: 

foreground, where scanning is the only activity; 

background, where communications with the current serving cell are maintained in parallel with the 
scanning, and the scanning causes no interruption to that service; 

interrupting, where communications with the current serving cell are maintained in parallel with the 
scanning, but the scanning causes limited interruptions to that service. 

23.7.5.2.1 Foreground scanning 

Foreground scanning is used when the MS is in idle mode on the serving cell and wishes to scan an 
adjacent cell. The MS switches from the serving ceil main carrier to the adjacent cell main carrier. The MS 
then acquires synchronisation and makes the adjacent cell measurements before returning to the serving 
cell main carrier. 

The MS MAC shall carry out the following in response to an MLE instruction to perform foreground 
scanning: 

change frequency to the channel to be scanned in the adjacent cell; 

attempt to acquire synchronisation on the channel to be scanned and decode the cell selection 
parameters in BNCH. If the BNCH cannot be decoded within 5 seconds, the scanning shall be 
stopped; 

measure the received RF signal strength or equivalent received signal quality. These 
measurements shall be used for calculating C1. The averaging shall be calculated using at least 5 
measurement samples, each sample having a duration of at least SD2 (as defined in clause 10). As 
far as possible, these samples should be evenly spread over at least 300 ms; 



calculate C1 for the scanned channel; 



return to the serving cell main carrier. 
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The MAC may decode the cell selection parameters at the same time as making the RSSI or equivalent 
measurements. Any measurements made within the 5 seconds before the start of scanning may also be 
used to calculated. 

In the case where the BS is operating in timesharing mode, the measurements shall be made during the 
timeslots exclusively reserved to the scanned channel and the number of periods may be reduced to the 
number of active timeslots over a period of two multiframes. 

23.7.5.2.2 Background scanning 

Background scanning is used when the MS wishes to scan an adjacent cell and maintain any current 
service on the serving cell, whether that is receiving the downlink control channel or transmitting or 
receiving as part of a call. The MS switches from the serving cell main carrier to the adjacent cell carrier in 
between any transmissions or receptions on the serving cell. The MS attempts to acquire synchronisation 
on the adjacent cell during those times. 

The signal strength measurements shall be identical to those performed during monitoring (see 
subclause 23.7.4.3). 

The MAC shall attempt to synchronise and read the BNCH and BSCH for the scanned channel. The MAC 
shall devote all its monitoring capability to these operations. The parameters decoded on the BNCH shall 
be used to calculate the path loss parameter C1 . 

The MAC shall keep the information concerning the time synchronisation for the channels of the list. This 
information may be used to schedule the subsequent decoding of cell selection parameters and shall be 
used when accessing a re-selected cell. 

When a new channel for which the MAC does not have synchronisation has to be scanned, the MAC shall 
devote all its monitoring capability to synchronise on this channel and read the cell selection parameters 
contained in the BNCH, in priority over signal strength measurements on all other channels. If the cell 
selection parameters cannot be read within 15 seconds, a re-attempt shall not take place before 
Attempt_number x 15 seconds after the end of the last attempt period, Attempt_number being the number 
of attempts already performed. 

The MAC shall attempt to read the cell selection parameters of each of the channels of the list at least 
every minute, to confirm that it is monitoring the same cell and update the value of these parameters. If a 
change of identity is detected then the channel shall be treated as a new channel in the list. If the BSCH 
cannot be decoded, a re-attempt shall be made at the next available opportunity. 

For initial and subsequent cell selection parameters decoding, if the cell selection parameters cannot be 
decoded after 5 attempts, its channel shall be discarded from the list and any existing signal strength 
measurements shall be discarded. 

The MAC shall re-calculate the parameter C1 at least every 10 seconds for the channels of the list based 
on the updated measurement done by monitoring (C2). 

23.7.5.2.3 Interrupting scanning 

Interrupting scanning is similar to foreground scanning except that the MS is participating in a call on the 
serving cell and temporarily suspends service in order to scan an adjacent cell. 

The signal strength measurements shall be identical to these performed during monitoring 
(see subclause 23.7.3). 

The MAC shall attempt to synchronise, read the cell selection parameters and calculate the path loss 
parameter C1 for all channels as instructed by the MLE. 

The MAC shall devote all its resources to these operations. If the cell selection parameters cannot be read 
within 5 seconds for a channel, ail signal strength measurements on this channel shall be discarded. 
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The MAC shall keep the information concerning the time synchronisation for the channels. This 
information may be used to schedule the subsequent decoding of cell selection parameters and when 
accessing a re-selected cell. Whenever the MAC re-calculates the parameter C2 for one of these 
channels, it shall re-calculate the parameter C1 for this channel. The MAC may periodically attempt to 
read the cell selection parameters for these channels, to confirm that it is monitoring the same cells and 
update the value of these parameters. 

In the case where the radio link is relinquished before the link is declared relinquishable, the MAC shall 
first check all channels for which it has kept the time synchronisation according to the indication given by 
the MLE. If none of the channels meets this criterion, the MAC shall perform the cell selection parameters 
measurement as for unprepared cell selection. 

23,7.6 Selection of energy economy mode 

An MS may enter energy economy mode by negotiating with the BS. This negotiation shall be performed 
by an MM message exchange. Once MM has negotiated a particular energy economy group, the MAC 
shall be informed using MLE-INFO request, TL-CON FIGURE request and TMC-CONFIGURE request 
primitives. These primitives shall include two parameters: 

"Energy economy group"; and 

"Energy economy start point". 

"Energy economy group" shall specify how long the MS may sleep between receiving downlink slots on 
the control channel and shall have one of the values shown in table 352. "Energy economy start point" 
shall specify the frame and multiframe number at which energy economy operation shall begin. 

Table 352: Definition of the Economy Groups and duration 



Economy Group 


Frames to sleep 


EG1 


1 


EG2 


2 


EG3 


5 


EG4 


8 


EG5 


17 


EG6 


71 


EG7 


359 



An MS shall only request to enter energy economy mode while on the MCCH or a common SCCH. It shall 
receive and decode the relevant slot on the main carrier in all of the frames up until and including the 
frame and multiframe given by the "Energy economy start point". The MS may then sleep for the number 
of frames indicated by the "Energy economy group". After this number of frames has elapsed, the MS 
shall then receive and decode the relevant downlink slot in the next frame. This operation (i.e. the regular 
cycle of sleeping for N frames and then receiving in one frame) shall continue while the MS remains in 
energy economy mode. 

An energy economy mode shall be valid in all cells within a LA. If an MS changes cell within the LA, it may 
maintain the same energy economy mode and follow the same energy economy pattern after acquiring 
slot and. frame synchronisation on the new cell (but using the frame and multiframe numbering of the new 
cell). All energy economy groups have a cyclic energy economy pattern within a hyperframe and so, given 
a start point and energy group, the MS may calculate the absolute frame and multiframe numbers it must 
monitor. Therefore, even although adjacent cells need not be synchronised, an MS may apply the same 
energy economy pattern on the new cell within the LA. 

During energy economy mode, an MS shall temporarily suspend the sleeping cycle if: 
it is sent to an assigned channel, or 

it becomes active in an advanced link or call (e.g. indicated by the TMC-CONFIGURE request from 
the higher layers), or 

it has signalling messages to send, or 
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it receives a signalling message from the BS for any of its addresses or event labels other than the 
predefined broadcast group address (all ones). 

The MS shall return to the sleeping cycle when a time T.210 has elapsed since: 

it returned to the common control channel, or 

the higher layers indicated no activity (e.g. using the TMC-CONFIGURE request), or 
it sent its last signalling message, or 

it last received a signalling message from the BS for one of its addresses or event labels other than 
the predefined broadcast group address (all ones); 

whichever is the most recent. During this time-out period, the MS shall continue to receive the downlink 
MCCH or common SCCH slot for any further signalling from the BS. 

An MS shall end energy economy mode in the same way as it entered, i.e. via an exchange of MM 
messages with the BS and MM informing the MAC via the MLE-INFO request, TLC-CONFIGURE and 
TMC-CONFIGURE primitives and the "Energy economy group" set to "Stay alive" to return to receiving the 
common control channel during all frames. The MAC shall begin this immediately and so the "Energy 
economy start point" parameter shall have no meaning in this case. 

The MS shall end energy economy mode if it moves to a different LA. 

23.8 PDU transfer for traffic (TMD-SAP) 

23.8.1 Introduction 

For a message trunked system, a complete circuit mode call generally takes place on one assigned 
channel. Before any traffic transmission, the BS allocates a traffic usage marker for the call. 

For a transmission trunked system, each traffic transmission, i.e. "over", takes place on an assigned 
channel. Between "overs", the MS is directed to a common control channel or to an assigned SCCH. 
Before each traffic transmission, the BS allocates a traffic usage marker for use on the assigned channel. 

For a quasi-transmission trunked system, each traffic transmission takes place on an assigned channel. 
At the end of an "over", the MS(s) remain on the assigned channel for a short period, the channel 
hang-time. If another traffic transmission for the call is requested within the hang-time then the same 
channel is used for that traffic transmission. Otherwise, after the hang-time, the BS directs the MS(s) to a 
common control channel, or to an assigned SCCH, until the next traffic transmission is requested; the BS 
then assigns a channel for that traffic transmission, either the previous assigned channel or a different 
channel. Before any traffic transmission on an assigned channel, the BS allocates a traffic usage marker 
for use on that channel. 

The choice between these modes is made by the BS. The MS procedures operate independently of this 
BS choice. 

During a call; the slow ACCH is always available in frame 18. Also, when frames 1 - 17 are not being used 
for traffic, the fast ACCH is available in frames 1-17, (see subclause 23.3). In the case of independent 
allocation of uplink and downlink, or for an inter-site call, the availability of FACCH at any time may be 
independent on uplink and downlink. 

The usage of both uplink and downlink is indicated, independently, in the AACH. A traffic usage marker is 
used when the corresponding direction is in use for traffic, i.e. TCH or STCH. During FACCH, the uplink is 
controlled by the access field, and the downlink is marked with the assigned control or common control 
pre-set usage marker as appropriate. 

In traffic mode, on frames 1-17, capacity may be stolen from the circuit for signalling purposes, without 
changing the current mode of operation. The half-slot training sequence indicates when stealing has 
occurred and the MAC header in the first half slot indicates whether the second half slot is also stolen. 
This mechanism applies to both uplink and downlink. 
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See clause 19 for the configuration of the lower MAC in signalling and traffic mode. The default mode is 
signalling mode. 

NOTE: The STCH mechanism applies only when the channel is in traffic mode, allowing 
signalling messages to be sent within an "over", and without waiting for frame 18. For 
example: U-plane signalling, user-to-user signalling and/or encryption synchronisation, 
is sent on STCH; CC PDU U-TX-CEASED should normally be sent on STCH; and 
D-TX-CEASED may be sent on STCH. C-plane signalling messages unrelated to the 
call may also be sent on STCH. Between "overs" on a message trunked (or quasi- 
transmission) trunked system, the assigned channel will normally return to signalling 
mode (FACCH). The SCH procedures then apply. 

23.8.2 Criteria for transmission and reception of traffic 

During a circuit mode call: 

a sending MS needs to be instructed when to start sending traffic (and when to stop); 

a receiving MS needs to know when to process any received TCH (and when to stop). 

This process shall be performed by CC messages sent by the BS to the appropriate MS(s). The CMCE in 
the MS shall then instruct the MS-MAC using the TMC-CON FIGURE request primitive. There are also 
some back-up mechanisms using the AACH. 

23.8.2.1 Use of TMC-CONFIGU RE primitive 

For the purpose of the protocol description, it is assumed that the instruction from the CMCE for changing 
the operating mode in the MS-MAC comprises the following sub-parameters: 

switch U-plane on/off; 

Tx-grant flag; 

simplex/duplex flag; 

type of circuit (i.e. TCH/S, TCH/2 ,4, TCH/4,8, TCH/7,2); 
interleaving depth N; 
encryption flag; 
call identifier; 
user device; 
endpoint identifier. 
The possible combinations of the first three sub-parameters may be: 

a) Switch U-plane on, Tx-grant, Simplex: MS is authorised to transmit TCH; 

b) Switch U-plane on, Not Tx-grant, Simplex: MS is authorised to receive TCH; 

c) Switch U-plane on, Tx-grant t Duplex: MS is authorised to transmit and receive TCH; 

d) Switch U-plane off: Withdraws previous authorisation to transmit 

and/or receive TCH. 

The upper MAC shall inform the lower MAC of the appropriate type of TCH logical channel for 
transmission and/or reception since this affects the coding/decoding method. 
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NOTE 1 : In case a) above, the MS continues to receive the downlink in the normal manner 
subject to the defined monitoring pattern(s) and using the procedures in 
subclause 23.5.6.3 for interpretation of the downlink. The downlink may be either in 
signalling or traffic mode. 

NOTE 2: If the MS has independent circuit mode calls in progress on the uplink and downlink of 
the channel, the MAC should use the call identifier to distinguish between the operating 
mode instructions from the CMCE. 

NOTE 3: The MAC may receive changes to the operating mode for the same call, with 
consecutive changes both containing the instruction to "Switch U-plane on". For 
example, this may occur if the next traffic transmission has already been requested so 
that there is no need to return to signalling mode. The most recent instruction for the 
call over-writes previous instructions, e.g. case b) after case a) withdraws the TCH 
transmit authorisation and gives TCH receive authorisation. Case a) after case b) 
withdraws the TCH receive authorisation and gives TCH transmit authorisation. 

NOTE 4: For the purposes of the protocol description, it is assumed that the process of the MAC 
issuing a TMA-UNITDATA indication primitive containing a CC message and then 
receiving the corresponding TMC-CONFIGURE request primitive is effectively 
instantaneous. 

23.8.2.2 Timing of change of mode 

For a switch to U-plane transmission, the MS shall use the following timings. 

If the downlink slot containing the transmit permission (or the final fragment) contained no channel 
change and no slot grant, then: 

if in frames 1-17, the MS shall start sending traffic in the corresponding uplink slot in that 
TDMA frame; 

if in frame 18, the MS shall start sending traffic in frame 1 . 

NOTE1: If the MS has received previous slot grants on the assigned channel then the MS 
should assume that any granted slots in frames 1 - 17 are withdrawn whereas any 
granted slots in frame 18 are still valid. 

If the downlink slot containing the transmit permission, or the final fragment, contained a slot grant, 
either with no channel change or with a grant on the assigned channel, then the MS shall start 
sending traffic in the next full uplink slot on the assigned channel in frames 1-17, following the end 
of the grant. This rule applies even if the grant exceeds the MS's requirement to send signalling 
messages. Note 1 applies to any previous slot grants on the assigned channel. 

If the downlink slot containing the transmit permission, or the final fragment, contained a channel 
change and no slot grant on the assigned channel, then: 

if CLCH permission is given then the MS shall start sending traffic in the next uplink slot on 
the assigned channel in frames 1-17. This is the next valid full uplink traffic slot following the 
slot containing the potential CLCH subslot, even if the MS does not need to use CLCH; 

if CLCH permission is not given, e.g. no change of RF carrier, then the MS shall start sending 
traffic in the first uplink slot on the allocated channel as defined in subclause 23.5.4.3, if that 
slot is in frames 1 - 17; or else in frame 1 . 

In the first traffic slot, and if the DATA-IN-BUFFER signal from the LLC indicates that there is a message 
in the buffer with the stealing permission parameter set to "steal within time T.214" or "steal immediately", 
then the MS-MAC shall issue a MAC-READY signal to the LLC offering stolen capacity, e.g. for a layer 2 
acknowledgement to the layer 3 transmit permission message. 
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For a switch to U-plane reception, with no channel change: 

for a single-slot channel, or for a multi-slot channel in which the next downlink slot is not part of that 
channel, the MS shall switch to U-plane reception at the end of the downlink slot containing the 
receive permission; 

for a multi-slot channel, and if the next downlink slot is part of that channel, the MS shall delay the 
switch to U-plane reception by one timeslot duration. 

NOTE 2: For example: for a multi-slot channel comprising timeslots 2, 3 and 4, with a switch 
instruction in downlink slot 2, the MS assumes SCH for downlink slot 3 and then 
switches to U-plane reception for downlink slot 4. Whereas, if the switch instruction is 
in downlink slot 4 then the MS switches to U-plane reception for downlink slot 2 in the 
next frame. 

For a switch to U-plane reception, with a channel change, the MS shall switch to U-plane mode when it 
moves to the allocated channel for reception of the first downlink slot on the allocated channel as defined 
in subclause 23.5.4.3. 

For a switch out of U-plane transmission: 

for a single-slot channel, or for a multi-slot channel in which the next uplink slot is not part of that 
channel, the MS shall switch mode immediately, i.e. as soon as the downlink message has been 
processed; 

for a multi-slot channel, and if the next uplink slot is part of that channel, the MS shall delay the 
switch by one timeslot duration. 

NOTE 3: For example: for a multi-slot channel comprising timeslots 2, 3 and 4, with a switch 
instruction in downlink slot 3, e.g. in frame 10, the MS continues to transmit TCH in 
uplink slot 2 before switching. Whereas, if the switch instruction is in downlink slot 2 
then the MS stops U-plane transmission at the end of the coinciding uplink slot 4. 

For a switch out of U-plane reception: 

for a single-slot channel, or for a multi-slot channel in which the next downlink slot is not part of that 
channel, the MS shall switch mode at the end of the downlink slot containing the switch instruction; 

for a multi-slot channel, and if the next downlink slot is part of that channel, the MS shall delay the 
switch by one timeslot duration. 

NOTE 4: For example: for a multi-slot channel comprising timeslots 2, 3 and 4, with a switch 
instruction in downlink slot 2, the MS assumes TCH for downlink slot 3 and SCH for 
downlink slot 4. 

NOTE 5: If the BS does not receive an expected layer 2 acknowledgement to a downlink 
message giving or withdrawing authorisation to receive traffic on the downlink, it 
cannot know whether the MS actually received the message; therefore, it cannot know 
whether the MS is in signalling or traffic mode for reception. In either case, if the BS 
wishes to send a re-transmission, it is necessary that the MS is able to interpret the 
downlink channel correctly. At this time, it is recommended that the BS uses only the 
half-slot training sequence, sending either STCH + STCH or SCH/HD + SCH/HD. 
Interpretation of these forms by MSs is very similar, provided that the BS uses only 
"length indication- 11 11 IO2 or 111 11 1 2 in the last PDU in a first half slot, even if that 
half slot actually contains SCH/HD. 

NOTE 6: After being authorised to receive traffic, the MS switches to traffic mode almost 
immediately. If TCH from the source is not ready at this time, the BS should send 
C-pIane STCH + STCH on the downlink, e.g. containing Null PDUs. 
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NOTE 7: As specified above, the switch out of U-plane mode is almost immediate after the 
CMCE has received the command from the BS. Therefore, for a circuit mode data call 
with an interleaving depth of N = 4 or 8, the CMCE in the transmitting MS should 
ensure that the MS has been able to issue N-1 slots containing tail bits (zeros) to the 
lower MAC at the end of the required data transmission, on each allocated slot in the 
case of a multi-slot channel, before sending the U-TX-CEASED PDU to the BS. These 
tail bits are needed to complete the interleaving of the real data. 

23.8.2.3 AACH mechanisms 

The following procedures specify criteria for stopping transmitting or receiving traffic. There are also 
criteria for leaving an assigned traffic channel, based on received AACH, (see subclause 23.5.6. for 
maintenance of an assigned channel). 

23.8.2.3.1 MS transmitting traffic 

The MS shall not transmit traffic unless authorised by a CC message. During traffic transmission, the MS 
shall receive and attempt to decode the downlink assigned channel for at least those frames defined by 
the monitoring pattern information within the capabilities of that MS. 

After starting to transmit traffic, and if the BS does not allow U-plane DTX, discontinuous traffic 
transmission by the MS, then the MS shall transmit traffic, TCH and/or STCH, in frames 1 - 17, in 
successive slots on the uplink assigned channel, as defined by element "timeslot assigned", until any one 
of the following criteria a), b), c) or d) occurs. 

NOTE 1 : The "U-plane DTX** element in the SYNC PDU indicates whether or not the BS 
supports discontinuous traffic transmission by the MS. 

After starting to transmit traffic, and if the BS allows U-plane DTX, then the MS may transmit traffic (TCH 
and/or STCH) in frames 1 - 17 on the uplink assigned channel, and shall transmit in at least one traffic slot 
every T.213 TDMA frames, until any one of the following criteria a), b), c) or d) occurs. 

a) Authorisation to transmit traffic is withdrawn, either by an instruction to switch the U-plane off or by 
a switch from transmit to receive for this call. 

b) if one or more monitoring patterns were assigned, i.e. element "Monitoring Pattern- * OO2: 

N.211 successive ACCESS-ASSIGN PDUs received in frames 1-17 on the downlink 
assigned channel contain "Header" * H2 or do not contain the correct uplink traffic usage 
marker; 

if no monitoring pattern was assigned, i.e. element "Monitoring Pattern" = OO2: 

N.211 successive ACCESS-ASSIGN PDUs received in any frame on the downlink assigned 
channel contain "Header" * 1 1 2 or do not contain the correct uplink traffic usage marker. 

c) If one or more monitoring patterns were assigned, i.e. element "Monitoring Pattern" * 00 2 : 

a time T.211 elapses without receipt of an ACCESS-ASSIGN PDU in frames 1 - 17 on the 
downlink assigned channel, containing "Header" = 11 2 and containing the correct uplink 
traffic usage marker; 

if no monitoring pattern was assigned, i.e. element "Monitoring Pattern" = 00 2 : 

a time 18 * T.21 1 elapses without receipt of an ACCESS-ASSIGN PDU in any frame on the 
downlink assigned channel, containing "Header" = 11 2 and containing the correct uplink 
traffic usage marker, as "Field 2" in frames 1 - 17 or "Field 1" in frame 18. 

d) The MS leaves the assigned channel (see subclause 23.5.6.1). 



In all cases, the MS shall stop transmitting traffic, TCH and STCH, and shall revert to the normal C-plane 
methods of random access and reserved access in all frames 1-18. 
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In cases b) or c), the MS-MAC shall report the change of mode to the higher layers using the 
TMC-REPORT indication primitive. 

In case d), the interruption may be only temporary. If the MS is changing channel on instruction from the 
BS and if: 

the "Allocation Type" = 00 2 or 1 1 2 ("Replace" or "Replace + CSS channel"); and 

the MS is being directed to an assigned channel (i.e. element "Timeslot Assigned" * OOOO2); and 

the uplink is assigned (i.e. element "Up/downlink Assigned" = IO2 or 1 12); and 

the MS receives a traffic usage marker assignment with the channel allocation; and 

the MS does not receive a CMCE message withdrawing authorisation to transmit traffic; 

then, on receipt of the channel allocation, the MS-MAC shall stop transmitting traffic on the current 
channel. For a single-slot channel, or for a multi-slot channel in which the next uplink slot is not part of that 
channel, the MS shall stop transmitting traffic immediately. For a multi-slot channel, and if the next uplink 
slot is part of that channel, the MS shall delay the switch by one timeslot duration. 

After changing channel, the MS shall continue traffic transmission as follows: 

if the MS has a slot grant on the assigned channel 

then the MS shall continue traffic transmission in the next uplink slot on the assigned channel 

(in frames 1 - 17} , following the end of the slot grant 

else 

if "Immediate CLCH permission" is given 

then the MS shall continue traffic transmission in the next full uplink slot on the assigned 
channel (in frames 1 - 17), following the slot containing the potential CLCH subslot 
else the MS shall continue traffic transmission in the first uplink slot on the allocated channel 
(as defined in subclause 2 3.5.4.3) if that slot is in frames 1 - 17 or otherwise in frame 1. 

This rule shall apply both for allocation within the same cell and for a different cell (seamless handover). 

For a channel change that does not conform to the above, the MS-MAC shall stop transmitting traffic and 
shall report the change of mode to the higher layers. 

If, after starting to transmit traffic and at any time other than during a temporary interruption for channel 
change, the MS receives a slot grant addressed to itself, and granting a reserved uplink subslot or slot(s) 
in frames 1-17, i.e. where it expected to transmit traffic, then the MS-MAC shall stop transmitting traffic, 
reporting the change of mode to the higher layers. 

NOTE 2: The scenario above should not occur except in case of transmission errors. It is not 
intended for use by the BS as a normal method for ending U-pIane transmission. 

NOTE 3: Criterion b) refers to a check on those ACCESS-ASSIGN PDUs that are successfully 
decoded by the MS, irrespective of whether or not these are in successive slots on the 
assigned channel. Then criterion c) covers the case when the AACH is not 
successfully decoded during the specified time. If no monitoring pattern is assigned, 
the BS should use "Header" 11 2 in ACCESS-ASSIGN PDUs in frame 18 on the 
downlink assigned channel, including the traffic usage marker of the transmitting MS. 

NOTE 4: The "channel replace" mechanism, without withdrawal of transmit authorisation may be 
used within the cell, for convenience of BS resource allocation, or between cells e.g. 
for seamless handover. Before continuing U-plane transmission, the MS may be 
required to transmit a C-plane reply, in a reserved slot on either the current or 
allocated channel, or by stealing. Alternatively, the BS may prefer to interrupt the traffic 
transmission by sending the CMCE PDU D-TX-WAIT (temporarily withdrawing 
transmit permission). 
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23.8.2.3.2 MS receiving traffic 

The MS should process received traffic after authorisation by a CC message. 

Also, the MS may process received traffic without specific authorisation if N.213 ACCESS-ASSIGN PDUs 
received in frames 1 - 17 in successive slots appropriate to the downlink assigned channel contain 
Header * 00 2 and contain the correct downlink traffic usage marker for this MS. The MS-MAC should 
report the change of mode to the higher layers using the TMC-REPORT indication primitive. 

The MS shall process any received traffic, TCH and STCH, in frames 1 - 17 in slots on the downlink 
assigned channel until any one of the following occurs: 

a) authorisation to receive traffic is withdrawn (either by an instruction to switch the U-plane off or by a 
switch from receive to transmit for this call); 

b) N.212 successive ACCESS-ASSIGN PDUs received in frames 1 - 17 on the downlink assigned 
channel contain "Header" = OO2 or do not contain the correct downlink traffic usage marker; 

c) a time T.212 elapses without receipt of an ACCESS-ASSIGN PDU in frames 1 - 17 on the downlink 
assigned channel, containing "Header" * 00 2 and containing the correct downlink traffic usage 
marker; 

d) the MS leaves the assigned channel (refer to subclause 23.5.6.1), unless the criteria described 
below are satisfied. 

In all cases, the MS shall stop processing received traffic. 

In cases b), c) or d), the MS-MAC shall report the change of mode to the higher layers using the 
TMC-REPORT indication primitive. 

In all cases, the MS may again process received traffic either after authorisation by a CC message or by 
using the "N.213 permission method" described above. 

The exception to case d) is that, if the MS changes channel on instruction from the BS and if: 

the "Allocation Type" = 00 2 or 1 1 2 ("Replace" or "Replace + CSS channel"); and 

the MS is being directed to an assigned channel (i.e. element "Timeslot Assigned" * 00002); and 

the downlink is assigned (i.e. element "Up/downlink Assigned" = 01 2 or 1 1 2 ); and 

the MS receives a traffic usage marker assignment with the channel allocation; and 

the MS does not receive a CMCE message withdrawing authorisation to receive traffic; 

then the MS-MAC shall switch out of U-plane reception at the end of the downlink slot containing the 
channel allocation, or, for a multi-slot channel, and if the next downlink slot is part of that channel and if 
the MS is still on the current channel to receive that slot, the MS shall delay the switch by one timeslot 
duration. The MS shall switch back to U-plane reception when it moves to the allocated channel, using the 
newly assigned usage marker, for reception of the first downlink slot on the allocated channel as defined 
in subclause 23.5.4.3. 

This rule shall apply both for allocation within the same cell and for a different cell. 

NOTE 1: Criterion b) refers to a check on those ACCESS-ASSIGN PDUs that are successfully 
decoded by the MS, irrespective of whether these are in successive slots on the 
assigned channel. Whereas the "N.213 permission method" applies only if 
ACCESS-ASSIGN PDUs are successfully decoded in successive traffic slots on the 
assigned channel. 



NOTE 2: The permission method based on parameter N.213 should not be used by an MS that 
is transmitting in simplex mode and that has only one circuit mode call on this channel 
i.e. the MS should not attempt to transmit and receive simultaneously in a simplex call. 
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NOTE 3: The "channel replace" mechanism, without withdrawal of receive authorisation may be 
used within the cell, for convenience of BS resource allocation, or between cells e.g. 
for seamless handover. If an MS that is receiving traffic is sent to a different timeslot 
during an end-to-end encrypted call, the BS may choose to interrupt the transmitting 
station with the D-TX-WAIT PDU, thereby causing the transmitting station to re-send 
encryption synchronisation when the transmission starts again. 

NOTE 4: In the case of circuit mode data, in order to avoid corrupting downlink data 
transmission, the BS designer may prefer (when possible) to send any channel 
allocation commands or D-TX-WAIT PDUs in frame 18. 

23.8.2.3.3 Multi-slot interleaving with interruption 

If a circuit mode data transmission is interrupted, either by use of the CMCE's D-TX-WAIT mechanism or 
by a "channel replace", as defined in the above two subclauses, then the MS shall continue with the 
transmission or reception of the data as if the intervening time out of U-plane mode had not been present. 
This rule includes the interleaving/de-interleaving of the data for interleaving depth N = 4 or 8. 

For a single-slot channel with N = 4 or 8, the MS shall continue to process the U-plane data after the 
interruption, performing interleaving/de-interleaving of the old data with the new data as traffic blocks are 
transmitted/received. 

For a multi-slot channel with N = 4 or 8, multiple single-slot data TCHs are operated in parallel in order to 
obtain the multi-slot TCH transmission as defined in subclause 23.3.5. After an interruption, the order of 
presentation of the data at the receiving side shall be maintained. Therefore, across the interruption, the 
single-slot TCHs may be linked between different timeslot numbers according to the next occurring traffic 
slot. 

NOTE: For example, for a multi-slot channel comprising timeslots 1 , 2 and 3, where a slot 1 is 
the last traffic slot before interruption and a slot 3 is the next traffic slot: 

the old interleaving process corresponding to slot 2 continues in slot 3; 
the old interleaving process corresponding to slot 3 continues in slot 1 ; 
the old interleaving process corresponding to slot 1 continues in slot 2. 

Similarly, for a multi-slot channel comprising timeslots 1, 2 and 3, with a new channel 
allocation comprising timeslots 1 , 3 and 4, where a slot 2 contained the last traffic on 
the old channel and a slot 3 contains the first traffic on the new channel: 

the old interleaving process corresponding to slot 3 continues in slot 3; 
the old interleaving process corresponding to slot 1 continues in slot 4; 
the old interleaving process corresponding to slot 2 continues in slot 1 . 

This second example could be caused either by use of the channel replace without 
withdrawal of U-plane authorisation, or by use of the D-TX-WAIT mechanism with a 
channel replacement during the pause. 

23.8.3 Exchange of information at the TMD-SAP 

In the protocol model, the actual user traffic is transferred between the U-plane application (e.g. the 
speech CODEC) and the MS-MAC via the TMD-SAP. The TMD-SAP is used for the transfer of speech 
frames or circuit mode data. It is also used if the U-plane application steals from the traffic capacity to 
send U-plane signalling. 

For the purposes of the protocol description, the following services primitives are used. However, this 
does not imply any implementation. The word "shall" is used with the primitives for traceability reasons in 
the protocol model, but the primitives are not testable. 

The TMD-UNITDATA request primitive shall be used when the U-plane application wishes to send 
information to the peer entity. 

The TMD-UNITDATA indication primitive shall be used for the MS-MAC to deliver information from 
the peer entity. 
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The TMD-REPORT indication shall be used by the sending MAC to issue reports to the U-plane 
application e.g. at the start and stop of traffic transmission, and if the MS changes channel within an 
"over", and when the MAC has stolen from the traffic capacity. It shall also be used by the receiving 
MAC at the start of a call. 

The parameters specific to the TMD-UNITDATA primitive are as follows (see to clause 20): 

a) Half slot content 

The unit of information in the TMD-UNITDATA primitive shall be one half slot. The U-plane 
application shall provide a TM-SDU of the correct size for the appropriate logical channel so that the 
MS-MAC does not have to insert filler bits to complete the MAC block nor have to remove filler bits 
on reception. 

In particular, when the U-plane application steals from the traffic capacity for U-plane signalling, the 
TM-SDU shall always be 121 bits. The upper MAC shall then add a 3-bit MAC header, making the 
MAC block up to the 124 bits required for STCH. The U-plane signalling may be for user-to-user 
signalling or for encryption synchronisation. However, the MAC is not aware the intended purpose 
of the U-plane signalling. Any necessary discrimination shall be included within the TM-SDU. 

User traffic TCH does not have a MAC header. 

b) Half slot position 

Each transferred half slot (in either direction) should be accompanied by a marker identifying it as 
the first or second half slot of a timeslot. 

At all points in the system, half slots should be grouped in pairs, equivalent to the data transmitted 
over the air interface in one slot. The binding between these pairs shall remain intact and the 
correct timing/ordering relationships with adjacent half slots preserved, even when a half slot is 
stolen and the half slots are processed separately by the MAC. 

c) Stolen indication 

At the transmitting side, this parameter shall indicate whether the half slot is stolen for U-plane 
signalling or not stolen. 

At the receiving side, this parameter shall indicate whether the half slot was stolen for C-plane 
signalling, stolen for U-plane signalling or not stolen. 

d) Half slot importance 

This parameter may be used only in the TMD-UNITDATA request primitive. It indicates the 
importance of the U-plane information, enabling the sending MS-MAC to decide when and whether 
to steal from the traffic capacity and to decide whether to use U-plane DTX (discontinuous traffic 
transmission). Four levels of importance are defined: no importance, and low, medium and high 
importance. 

e) Half slot condition 

This parameter may be used only in the TMD-UNITDATA indication primitive. It indicates to the 
receiving U-plane application whether a half traffic slot was received successfully. It may take the 
following values: 

"Good" if the half slot was de-codeable; 

"Bad" if a valid training sequence was detected but the CRC check failed; 
"Null" if no valid training sequence was detected. 
The distinction between "Good" and "Bad" is not appropriate for TCH/7,2. 
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f) User device 

The user device parameter shall identify the appropriate circuit. 

NOTE 1 : For the purposes of the protocol description, channel encoding and decoding are 
performed in the lower MAC. However, this does not imply any particular 
implementation. If, for example, the Implemented were to choose to perform the 
channel coding of TCH directly in the CODEC, then the descriptions of half slot 
transfer generally still apply (though the distinction between "Good" and "Bad" in the 
"half slot condition" parameter is no longer relevant). 

NOTE 2: For the purposes of the protocol description, the unit of exchange at the TMD-SAP is 
always a half slot (corresponding to one speech frame). However, this does not imply 
any particular implementation. For example, implementers may prefer to use a full slot 
of data as the unit of exchange for circuit mode data TCH. 

NOTE 3: It is assumed that the U-plane application provides valid data in the "half slot content" 
parameter even if the "half slot importance" is set to "no importance". 

23.8.3.1 Interface at transmitting MS 

At the start of a call (or before each "over), or if the basic service information changes, the MS-MAC shall 
issue a report to the U-plane application to supply the traffic type, the interleaving depth, the number of 
slots per frame, a flag indicating whether end-to-end encryption applies, the call identifier and the user 
device parameter. 

When the MS has been authorised to transmit TCH, and has established whether it will steal the first half 
slot for C-plane signalling, e.g. a layer 2 acknowledgement, 

the MS-MAC shall issue a report to the U-piane application. This report shall indicate the initial half slot 
synchronisation i.e. whether the first valid U-plane half slot is a first or second half slot; that half slot may 
then be used either for TCH or for U-plane signalling. 

A report should be issued to the U-plane application if there is any interruption (e.g. a channel change) so 
that, for an end-to-end encrypted call, the U-plane application can send encryption synchronisation again. 

A report should also be issued to the U-plane application when traffic transmission is no longer permitted. 

When transmitting a slot in traffic mode, the sending MS-MAC is generally given the first half slot by the U- 
plane application, in a TMD-UNITDATA request primitive. That half slot may be either TCH, or U-plane 
signalling in the case of stealing by the U-plane application. 

If the MS-MAC decides to steal the first half slot for C-plane signalling then the MAC should issue a TMD- 
REPORT indication, enabling the U-plane application to revise the intended use of the second half slot. 

The MS-MAC is then given the second half slot in another TMD-UNITDATA request primitive. Again, if the 
MS-MAC decides to steal the half slot for C-plane signalling then the MAC should issue a TMD-REPORT 
indication. 

In the case of circuit mode data with low or high protection: if the U-plane application steals the first half 
slot but not the second half slot then it should issue two TMD-UNITDATA request primitives for the first 
half slot (one containing the stealing information and the other containing TCH) and one TMD-UNITDATA 
request primitive for the second half slot (containing TCH). In the case of circuit mode data with 
interleaving depth N = 4 or 8: if the U-plane application steals both half slots then it should issue two TMD- 
UNITDATA request primitives for each half slot (one containing the stealing information and the other 
containing TCH). 
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At this time, the MS-MAC has the contents of one slot. Permitted combinations for the two half slots are 
as follows: 



a) 


Not stolen i.e. TCH/Not stolen i.e. TCH; 


b) 


Stolen for C-plane/Not stolen i.e. TCH; 


c) 


Stolen for U-plane/Not stolen i.e. TCH; 


d) 


Stolen for C-plane/Stolen for C-plane; 


e) 


Stolen for C-plane/Stolen for U-piane; 


0 


Stolen for U-plane/Stolen for C-plane; 


g) 


Stolen for U-plane/Stolen for U-plane. 



In case a), and if the BS allows U-plane DTX, the MS may decide not to transmit in the slot, based on the 
"half slot importance" of the two half slots. If the MS transmits in the slot then the full-slot training 
sequence shall be used, with a full slot of TCH (MAC-TRAFFIC PDU). In all the other cases, the half-slot 
training sequence shall be used and the stealing procedure described in subclause 23.8.4 shall apply. 



In cases b) and c), for a speech call or unprotected data, the upper MAC shall issue a half slot of STCH 
and a half slot of TCH to the lower MAC. In cases d), e), f) and g), for a speech call or unprotected data, 
the upper MAC shall issue two half slots of STCH to the lower MAC. 

In cases b) and c), for a circuit mode data call with low or high protection, the upper MAC shall issue both 
a half slot of STCH and a full slot of TCH to the lower MAC. In cases d), e), 0 and g), for a circuit mode 
data call with N = 4 or 8, the upper MAC shall issue two half slots of STCH and also a full slot of TCH to 
the lower MAC. 



NOTE 1: Not stolen + Stolen for C-plane is not a permitted combination. If the MAC receives 
Not stolen + Stolen for U-plane from the U-plane application, it could use case e), 
replacing the traffic with a dummy C-plane message (no TM-SDU). However, this 
would make inefficient use of the channel. It is recommended that the U-plane 
application does not request this form. 

NOTE 2: In an implementation, it may be preferred that, when practicable, the MAC informs the 
U-plane application as soon as it knows that it will perform C-plane stealing. For 
example, for a high priority C-plane message, the MAC may intend to steal irrespective 
of the U-plane half slot importance. 

NOTE 3: The above procedure specifies that, for protected circuit mode data with stealing in a 
slot, the upper MAC may issue both the STCH and a full slot of TCH to the lower MAC. 
This is because, for protected circuit mode data, the lower MAC replaces traffic bits 
with STCH bits after normal coding and interleaving of the TCH (see clause 8). This 
contrasts with the method for speech, where the second half slot is half-slot 
interleaved if the first half slot is stolen. 



23.8.3.2 Interface at receiving MS 

At the start of a call, or if the basic service information changes, the receiving MS-MAC shall issue a 
report to the U-plane application to supply the traffic type, the interleaving depth, the number of slots per 
frame, a flag indicating whether end-to-end encryption applies, the call identifier and the user device 
parameter. 

The following procedures in this subclause shall apply for reception in frames 1 - 17 by an MS that is 
authorised to receive TCH. 



TCH shall be passed to the U-plane application. 

U-plane signalling shall be passed to the U-plane application after removal of the 3-bit MAC header. 
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C-plane STCH shall be processed by the MAC, and any suitably addressed TM-SDUs shall be passed to 
the LLC. 

In all cases, for each half slot, the MS-MAC shall issue the TMD-UNITDATA indication primitive to the 
U-plane application containing any U-plane information (TCH or STCH) and indicating whether the half 
slot was stolen for C-plane signalling, stolen for U-plane signalling or not stolen. 

For protected circuit mode data, in the case of a slot in which only the first half slot was stolen, the upper 
MAC should receive a half slot of STCH and a full slot of TCH from the lower MAC. The upper MAC shall 
issue two TMD-UNITDATA indication primitives to the U-plane application containing TCH, one for each 
half slot, and also, for U-plane stealing, one TMD-UNITDATA indication primitive containing the stealing 
information in the first half slot. For circuit mode data with N = 4 or 8, in the case that both half slots are 
stolen, the upper MAC should receive two half slots of STCH and a full slot of TCH from the lower MAC. 
The upper MAC shall issue two TMD-UNITDATA indication primitives to the U-plane application 
containing TCH and also, for U-plane stealing, the appropriate TMD-UNITDATA indication primitive(s) 
containing the stealing information. 

In the case of un-decodeable TCH, the MS-MAC may pass the received data to the U-plane application, 
but shall set the "half slot condition 11 parameter appropriately in the TMD-UNITDATA indication primitive. 

23.8.4 Stealing from circuit mode capacity 

23.8.4.1 Uplink stealing 

23.8.4.1 .1 Transmission on uplink STCH 

Transmission on STCH shall only be used by an MS that has been authorised to transmit traffic. 
The appropriate PDUs for C-plane STCH on the uplink shall be: 

MAC-DATA PDU: first or second half slot; 

MAC-END PDU: second half slot only (final fragment). 

The appropriate PDU for U-plane STCH shall be: 

MAC-U-SIGNAL PDU: first or second half slot. 

The MAC header of a MAC-U-SIGNAL PDU sent in a first half slot shall indicate whether the second half 
slot is also stolen, second half slot stolen flag. If the second half slot is stolen, it may contain either 
U-plane or C-plane signalling as indicated by the first MAC header in the second half slot. 

For C-plane stealing within the first half slot, PDU association may be used. The "Length indication" in the 
last MAC-DATA PDU, or in the only MAC-DATA PDU, in the first half slot shall indicate whether the 
second half slot is also stolen. 

i) "Length indication" < 01 0000 2 : second half slot not stolen. 
Then the second half slot shall contain TCH (MAC-TRAFFIC PDU). 

ii) "Length indication" = 1 1 1 1 1 0 2 : second half slot stolen, no fragmentation. 

Then the second half slot may contain either U-plane or C-plane signalling (as indicated by the first 
MAC header in the second half slot). For C-plane signalling, PDU association may be used within 
the second half slot. 

iii) "Length indication" = 11 1 1 1 1 2 : second half slot stolen, start of fragmentation. 

Then the final fragment shall be sent in the second half slot (except in case of cancellation), using 
the MAC-END PDU. If PDU association is used within the second half slot, then the fragment shall 
be sent as the first PDU in the MAC block. 
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After transmitting a C-plane TM-SDU, the MS-MAC shall report to the LLC that the message has been 
sent by stealing (using the TMA-REPORT indication primitive). 

23.8.4.1 .2 Criteria for uplink stealing 

When an MS is authorised to transmit traffic, the MS-MAC may steal from the traffic capacity to send 
C-plane signalling. The MS then sends C-plane signalling instead of the data received from the U-plane 
application. The MS-MAC shall not move the replaced U-plane data (neither traffic nor signalling) to a 
different half slot or slot. 

The MS-MAC should report C-plane stealing to the U-plane application, enabling the application to revise 
the intended use of subsequent half slots, or to retransmit any U-plane signalling that has been 
overwritten by the MAC. 

The following procedures shall apply for the different settings of the stealing permission parameter for the 
C-plane message. 

a) Steal immediately 

The MS-MAC shall send the C-plane message at the first opportunity on the uplink assigned 
channel, without regard to the half slot importance. This rule shall apply to both one- and two- 
half-slot messages. 

For this setting of the stealing permission parameter, and if the MS is authorised to transmit traffic, 
the MS-MAC shall use stealing in preference to using random access or reserved access on 
frame 18. 

b) Steal within timeT.214 

If the MS has not been granted a reserved subslot or slot in frame 18, i.e. in the uplink SACCH for 
this channel, then the MS-MAC shall send the message within the next T.214 traffic slots on the 
uplink assigned channel, i.e. within the next T.214 TDMA frames 1-17 for a single-slot channel. This 
rule shall apply to both one- and two-half-slot messages. 

The MS-MAC should send the message in the first slot for which the half slot importance is not 
"high". Or, if this does not occur within T.214 - 1 slots, the MS-MAC shall send the message in the 
T:214'th traffic slot on the uplink assigned channel, without regard to the half slot importance. 

c) Steal when convenient 

The MS designer should choose suitable criteria for deciding when the MS-MAC may steal, based 
on the priority of the C-plane message, the half slot importance and the time since the last stealing 
occurrence. It is recommended that the MS-MAC does not re-steal over U-plane signalling. 

d) Stealing not required 

The MS-MAC should not use stealing to send the message, unless the half slot importance of the 
traffic is set to "no importance". 

The MS designer should note that frequent stealing would degrade the quality of the circuit. 

NOTE: The stealing permission parameter should be set to "steal immediately" for 
U-TX-CEASED, and U-DISCONNECT if currently transmitting traffic. The stealing 
permission parameter should be set to "steal within time T.214" for the reply to a BS 
message received while the MS is transmitting traffic, e.g. for a layer 2 
acknowledgement. For "steal within time T.214", the MS-MAC can plan when to steal 
based on the stealing permission parameter in the DATA-IN-BUFFER signal from the 
LLC. The MAC should not issue the MAC-READY signal until it is actually ready to 
send the message, thereby allowing the maximum time if the layer 3 in the MS is 
preparing a response to the BS message. 
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23.8.4.1.3 Stealing repeats mechanism 

When the MS-MAC has used stealing to transmit a C-plane PDU with stealing permission 
parameter = "steal immediately", it shall check the setting of the "stealing repeats flag" in the 
TMA-UNITDATA request primitive. For a message with stealing permission parameter * "steal 
immediately", or if this flag is not set, the MS-MAC shall regard the requested procedure as complete and 
shall discard the TM-SDU, i.e. it shall use the normal procedure. 

A special procedure shall apply for a message with "steal immediately" if the stealing repeats flag is set. 

Then the MS-MAC shall repeat the message on STCH, sending the message once per frame in 
successive traffic frames, i.e. frames 1 - 17, on the assigned uplink channel, until either: 

a) it has sent the message N.21 4 times (including the first transmission); or 

b) it has stopped transmitting traffic, e.g. as a result of a higher layer message or after AACH checks. 

In either case, the MS-MAC shall regard the requested procedure as complete and shall discard the 
TM-SDU. 

While the MS-MAC is performing the "stealing repeats" mechanism described above, it shall over-ride the 
normal monitoring pattern information, and shall attempt to receive and decode the downlink assigned 
channel in every frame. For a multi-slot channel, and if the MS is not frequency full duplex, the MS shall 
transmit only in the lowest numbered uplink slot appropriate to the assigned channel, sending its message 
in that slot. It shall attempt to receive and decode the lowest numbered downlink slot appropriate to the 
assigned channel in all frames 1-17, and all slots appropriate to the assigned channel in frame 18. 

If the MS-MAC stops the requested procedure on criterion a) above then it shall continue to use the 
modified rules for receiving and decoding the downlink channel for the T.251 frames following the N.21 4th 
transmission of the message. 

NOTE: The stealing repeats flag may be used by the higher layers to trigger this special 
stealing method in the MAC. This method is intended for signalling at the end of an 
uplink traffic transmission for U-TX-CEASED or possibly U-DISCONNECT. It provides 
a faster procedure for signalling the end of traffic transmission in case of propagation 
errors. Firstly, it allows more frequent repeats of the message. Also, the method of 
modifying the normal monitoring pattern and the structure of a multi-slot channel 
enables a faster response from the BS. This special procedure affects MAC operation 
only; the LLC re-transmission protocol is unchanged. The MAC should issue the 
TMA-REPORT indication to the LLC only after the first transmission of the message. 

23.8.4.1 .4 Reception on uplink STCH 

This subclause describes the procedure for BS reception on uplink slots that have been assigned for 
traffic. 

The training sequence in each slot shall indicate whether stealing has occurred. 

For the full slot training sequence (SF=0), the receiving BS shall assume that the slot contains only TCH. 

For the half slot training sequence (SF=1), the first half slot shall be assumed to be STCH. Then the MAC 
PDU type shall indicate whether the first half slot was stolen for C-plane signalling (MAC-DATA PDU) or 
for U-plane signalling (MAC-U-SIGNAL PDU). The receiving BS shall inspect the MAC header(s) to 
discover whether the second half slot is also stolen. 

For U-plane signalling, the "second half slot stolen flag" shall indicate whether the second half slot 
is stolen. 

For C-plane signalling, PDU dissociation may be necessary within the first half slot. 

If the last PDU (or only PDU) in the first half slot is a MAC-DATA PDU containing "Length 
indication" not equal to 1 1 1 1 1 0 2 nor 1 1 1 1 1 1 2, then the BS shall assume that the second half slot is 
not stolen. 
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If the last PDU (or only PDU) in the first half slot is a MAC-DATA PDU containing "Length 
indication" = 1111 10 2 or 1111 11 2 , the BS shall assume that the second half slot is stolen. Also, for 
"Length indication" = 1111 11 2 , the BS shall assume the start of fragmentation and shall store the 
TM-SDU fragment. 

If the second half slot is not stolen, the BS shall interpret the second half slot as TCH. 

If the second half slot is stolen, the BS shall interpret the second half slot as STCH. Then the MAC PDU 
type shall indicate whether the second half slot was stolen for C-plane signalling (MAC-DATA or 
MAC-END PDU) or for U-plane signalling (MAC-U-SIGNAL PDU). For C-plane signalling, PDU 
dissociation may be necessary within the second half slot. 

In the case of fragmentation: If the second half slot is not de-codeable, or if the second half slot does not 
include a MAC-END PDU, then the BS should discard the first fragment. Otherwise, it shall append the 
fragment from the MAC-END PDU to the already received fragment and shall assume that the received 
TM-SDU is complete. 

23.8.4.2 Downlink stealing 

23.8.4.2 Transmission on downlink STCH 

The BS may steal from a traffic circuit to send C-plane signalling messages on the downlink, either to the 
MS(s) receiving the traffic or to other MSs on the channel. However, the BS designer should note that 
frequent stealing would degrade the quality of the circuit, especially for circuit mode data calls. Also, it is 
recommended that, when the BS requires to steal, it steals from TCH in preference to overwriting U-plane 
signalling. This recommendation applies particularly to end-to-end encrypted calls. 

Valid PDUs for C-plane STCH on the downlink are: 

MAC-RESOURCE PDU: first or second half slot; 

SYSINFO PDU: first or second half slot; 

ACCESS-DEFINE PDU: first or second half slot; 

MAC-END PDU: second half slot only (final fragment). 

The appropriate PDU for U-plane STCH is: 

MAC-U-SIGNAL PDU: first or second half slot. 

The downlink MAC-U-SIGNAL PDU should be identical to that received from the transmitting station, 
except that the setting of the "second half slot stolen flag" may be changed when appropriate. 

The MAC header of a MAC-U-SIGNAL PDU sent in a first half slot shall indicate whether the second half 
slot is also stolen (i.e. second half slot stolen flag set). If the second half slot is stolen, it may contain 
either U-plane or C-plane signalling as indicated by the first MAC header in the second half slot. 

For C-plane stealing within the first half slot, PDU association may be used. The PDU type or "Length 
indication" in the last PDU (or only PDU) in the first half slot shall indicate whether the second half slot is 
also stolen. 

i) TMB-SAP PDU (SYSINFO or ACCESS-DEFINE): second half slot not stolen. 
Then the second half slot shall contain TCH (MAC-TRAFFIC PDU). 

ii) MAC-RESOURCE PDU with "Length indication" < 01 0000 2 : second half slot not stolen. 
Then the second half slot shall contain TCH (MAC-TRAFFIC PDU). 

iii) MAC-RESOURCE PDU with "Length indication" = 1 1 1 1 10 2 : second half slot stolen, no 

fragmentation. 
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Then the second half slot may contain either U-plane or C-plane signalling as indicated by the first 
MAC header in the second half slot. For C-plane signalling, PDU association may be used within 
the second half slot. 

iv) MAC-RESOURCE PDU with "Length indication" = 1 1 1 1 1 1 2 : second half slot stolen, start of 

fragmentation. 

Then the final fragment should be sent in the second half slot, using the MAC-END PDU. PDU 
association may be used within the second half slot. 

NOTE 1: The BS may use the Null PDU as a dummy C-plane message on STCH, in either the 
first half slot, second half slot or both. As always, "Address type" 000 2 in the MAC- 
RESOURCE PDU indicates a downlink Null PDU. In the first half slot, the "Length 
indication" indicates whether or not the second half slot is stolen. 

NOTE 2: The SYSINFO PDU cannot be sent in the first half slot if the second half slot is also to 
be stolen. If the second half slot is to be stolen, the ACCESS-DEFINE PDU can be 
included in the first half slot if required, but not as the last PDU (or only PDU) in the 
first half slot. 

23.8.4.2 Reception on downlink STCH 

This procedure shall be used by all MSs that are receiving the downlink channel. 

All MSs that are receiving the channel shall check whether C-plane messages are addressed to itself and, 
if so, shall process the message and deliver any TM-SDU to the LLC. Only MSs that are currently 
permitted to process received traffic shall pass the TCH, and the TM-SDU in U-plane signalling, 
MAC-U-SIGNAL PDU), to the U-plane application. 

The training sequence in each slot shall indicate whether stealing has occurred. 

For the full slot training sequence (SF=0), the receiving MS shall assume that the slot contains only TCH. 

For the half slot training sequence (SF=1), the first half slot shall be assumed to be STCH. Then the MAC 
PDU type shall indicate whether the first half slot was stolen for C-plane (TMA-SAP/TMB-SAP) or for 
U-plane (TMD-SAP) signalling. The receiving MAC shall inspect the MAC header(s) to discover whether 
the second half slot is also stolen. 

For U-plane signalling, the "second half slot stolen flag" shall indicate whether the second half slot 
is stolen. 

For C-plane signalling, PDU dissociation may be necessary within the first half slot. 

If the last PDU (or only PDU) in the first half slot is a TMB-SAP PDU, or a MAC-RESOURCE PDU 
(or Null PDU) containing "Length indication" not equal to 1111 10^ nor 11 111 1 2 , then the MS shall 
assume that the second half slot is not stolen. 

If the last PDU (or only PDU) in the first half slot is a MAC-RESOURCE PDU (or Null PDU) 
containing "Length indication" = 1 1 1 1 1 0 2 or 1 1 1 1 1 1 2 , the MS shall assume that the second half slot 
is stolen. Also, for "Length indication" = 111111 2 , the addressed MS(s) shall assume the start of 
fragmentation and shall store the TM-SDU fragment. 

If the first half slot is not de-codeable, the MS designer should choose an appropriate method for 
processing the second half of the slot. 

NOTE: For example, the MS might make a first assumption that the second half slot is stolen, 
but revise that decision if the CRC fails. This method could be particularly useful at the 
start of an encrypted transmission when encryption synchronisation might be sent in 
both halves of the slot. Otherwise the MS could treat the second half slot as "CRC fail" 
TCH. 

If the second half slot is not stolen, the receiving MS shall interpret the second half slot as TCH. 
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If the second half slot is stolen, the MS shall interpret the second half slot as STCH. Then the MAC PDU 
type shall indicate whether the second half slot was stolen for C-plane (TMA-SAP/TMB-SAP) or U-plane 
(TMD-SAP) signalling. If the second half slot is not de-codeable, the MS should regard the MAC block as 
C-plane signalling with CRC failure. 

In the case of C-plane signalling, PDU dissociation may be necessary within the second half slot. 

If the second half slot is not de-codeable, or if the second half slot does not include a MAC-END PDU, an 
MS-MAC that received a first fragment in the first half slot shall discard that fragment. Otherwise, it shall 
append the fragment from the MAC-END PDU to the already received fragment, and shall deliver the 
complete TM-SDU to the LLC. 

23.8.5 BS operation 

For traffic slots received on the uplink: 

a) for the full-slot training sequence, channel decoding (and re-encoding) may be performed at the BS, 
allowing error correction for multiple hops; 

b) channel decoding (and re-encoding) should be performed at the BS in the case of the half-slot 
training sequence, in order that the BS can recognise C-plane stealing; 

c) when a half slot has been stolen on the uplink for C-plane signalling then the BS should replace the 
stolen half slot, e.g. with another C-plane message or with the Null PDU or with substitution traffic, 
before transmission on the downlink. 

The BS should pass the U-plane signalling and TCH on towards the destination. The timing and ordering 
and half-slot pairing of the U-plane information (signalling and TCH) shall be preserved. The BS may 
replace, i.e. overwrite, U-plane information when performing C-plane stealing, but shall not move the 
replaced U-plane information to a different position. 

If the BS does not receive data from the sending MS, e.g. in the case of U-plane DTX, it should still 
transmit on the downlink channel to the receiving MS. For example, it could fill the slot with two stolen half 
slots each containing the C-plane Null PDU, or it could fill the slot with substitution traffic. 

Some examples of scenarios for call set-up and channel usage for circuit mode calls are illustrated in 
annex E. 

24 Connection Oriented Network Service (CONS) description (ISO 8348 and 
ISO 8878 delta) 

24.1 Introduction 

This clause which gives the service description of the TETRA connection mode CONS is based on the 
ISO document 8878 [9] and on ISO 8348 [5] network service definition. It gives the description of the 
relevant sections of the ISO 8878 document [9] which apply to TETRA and the specificity's. It describes 
the services offered at the layer 3 TNCO SAP. 

24.2 Organisation of this clause 

Subclause 24.4 refers to every clause of ISO 8878 [9]. The subclauses within subclause 24.4 correspond 
to each clause of ISO 8878 [9] respectively, e.g. subclause 24.4.3. corresponds to ISO 8878 [9], clause 3. 
For each ISO 8878 [9] clause, the parts that are relevant to TETRA are listed, and any specific additions 
or deletions are described. Where there are not detailed changes, subclause 24.4. will simply indicate 
whether the ISO 8878 [9] clause applies or not. 
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24.3 Service description 

The SAP corresponds to the TNCO SAP referred to in ETS 300 392-1 [11], clauses 12 and 13. The 
services offered shall be: 

virtual call set-up and clearing, the procedure is described in ISO 8208 [4] and in clause 25 of this 
ETS, during the network connection establishment phase. The call can be cleared at any time by a 
release phase by each side. This shall apply independently to each logical channel assigned to 
virtual call service. There shall be no set-up and clearing for Permanent Virtual calls (PVC); 

data transfer, the user data shall be passed transparently and unaltered, the order of bits is kept. 
The packet transfer applies independently to each logical channel assigned to virtual call and PVC. 
Acknowledged data transfer can be done; 

interrupt transfer, this shall allow to transmit data (1 to 32 octets) without following the flow control 
procedures applicable to data packets; 

reset, this shall be used to re-initialise a virtual call or PVC t it may be transmitted at any time; 

restart, this procedure shall be used to initialise or re-initialise the packet layer interface. The 
service visible to the user is only the indication of a restart. 

These services correspond to a set of primitives and associated parameters described in this ETS, based 
on ISO 8878 [9] where a mapping is given of the CONS primitives and parameters to the X25 PLP using 
virtual calls. The protocol is described in ISO 8208 [4], 

The following services shall not be offered: 

diagnostic, this service should be offered as a result of the reception of erroneous packet or a time 
out. This is used to indicate error conditions under circumstances where the usual method of 
indication, e.g. reset, clear, restart, are inappropriate e.g. unrecoverable error at layer 3; 

on line facility registration, on line facility registration shall be an optional facility agreed for a period 
of time to request registration of optional user facilities and/or to obtain the current values of such 
facilities; 

restart, the application cannot request a restart but may receive a restart indication; 

flow control, this service shall not be offered to the application but handled by CONP internally. 

24.4 ISO 8878 delta 

ISO 8878 [9] (version 1992-12-15) refers to ISO 8208 [4] X25/PLP (version 1990) equivalent to CCITT 
Recommendation X.25 (version 1988). 

24.4.1 Scope and field of application 

Text regarding "conforming 1980 implementation" is applicable to TETRA. 
X25/PLP 1 980 is applicable as previously mentioned. 

24.4.2 References 
Applicable to TETRA. 

24.4.3 Definitions 
Applicable to TETRA. 

24.4.4 Abbreviations 



Applicable to TETRA. 
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24.4.5 Overview 

24.4.5.1 Elements of the X25/PLP 1 984 used to support the OSI CONS 

Applicable to TETRA. This is further explained below. 

ISO gives a list of the packets and fields used to support the OSI CONP (see scenarios in figure 150 to 
figure 157 inclusive), the list does not cover all standard packets. 

The following packets are used for OSI CONS: 

CALL REQUEST, INCOMING CALL, CALL ACCEPTED, CALL CONNECTED, CLEAR REQUEST, 
CLEAR INDICATION, DATA, INTERRUPT, RECEIVE READY, RECEIVE NOT READY, REJECT, RESET 
REQUEST, RESET INDICATION, RESTART INDICATION (see table 353). 

The following packets are not used but are essential: 

CLEAR confirmation, INTERRUPT confirmation, RESET confirmation, RESTART confirmation. 

This means that they have no primitive equivalent but are essential to the packets used to support the OSI 
CONS, then they are not reported as primitives to the user application but they are required internally. 

The following packets have no relationship with the provision of the OSI CONS: 

RESTART request, DIAGNOSTIC, REGISTRATION request and confirmation. 



L3 



L3 



N-CONNECT request 



N-CONNECT confirm 



CALL REQUEST > 



INCOMING CALL > 
< CALL ACCEPTED 



CALL CONNECTED 



N-CONNECT indication 



N-CONNECT response 



Figure 150: Connection establishment scenario 



L3 



L3 



N-DIS CONNECT reques^ 



CLEAR REQUEST > 



CLEAR INDICATION > 



< CLEAR CONFIRMATION 



N-DISCONNECT indication 

> 



Figure 151: Disconnection scenario 

L3 L3 
< CLEAR REQUEST 



N-DISC O^NECT indication 



< CLEAR INDICATION 



N-DISCONNECT indication 

> 



Figure 152: Error detected and disconnection scenario 
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N-DATA request 



L3 



L3 



DATA 



DATA 



N-DATA request 



Figure 153: Data transfer scenario 



L3 



L3 



N -EXPEDI TED DATA reques^ 



INTERRUPT > 



< INTERRUPT CONFIRM 



N-EXPEDITED DATA indication 

> 



Figure 154: Expedited data transfer scenario 



L3 



L3 



N-RESET request 



N-RESET confirm 

< 



RESET REQUEST > 



RESET INDICATION > 



: RESET CONFIRMATION 

Figure 155: Reset scenario 

L3 



N-RESET indication 

> 



N-RESET response 



L3 



N-RESET indication 



RESET REQUEST 



RESET INDICATION 



Figure 156: Error detected and reset scenario 

L3 L3 
RESTART REQUEST 



N-DISCONNECT indication 

< 



4 



ESTART CONFIRMATION 



RESTART INDICATION 



N-DISCONNECT indication 

> 



Figure 157: Restart of the connection scenario 
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Table 350 gives the ISO 8878 [9] primitives and the corresponding ISO 8208 [4] packets. 



Table 350: Primitives and packet mapping 



Packet type 


ISO 8878 [91 primitive 


Comment 


CALL REQUEST 


N-CONNECT request 


see subclause 24.4. 


INCOMING CALL 


N-CONNECT indication 




CALL ACCEPTED 


N-CONNECT response 




CALL CONNECTED 


N-CONNECT confirm 




CLEAR REQUEST 


N-DISCONNECT request 
N-DISCONNECT indication 


see subclause 24.4.7. 


CLEAR INDICATION 


N-DISCONNECT indication 




CLEAR CONFIRMATION 




essential 


DATA 


N-DATA request 
N-DATA indication 


see subclauses 
24.4.9.and 24.4.8. 


INTERRUPT 


N-EXPEDITED DATA request 
N-EXPEDITED DATA indication 


see subclause 24.4.10. 


INTERRUPT CONFIRMATION 




essential 


RECEIVE READY 






RECEIVE NOT READY 






REJECT 






RESET REQUEST 


N-RESET request 
N-RESET indication 


see subclause 24.4.1 1 . 


RESET INDICATION 


N-RESET indication 




— 


N-RESET response 










RESET CONFIRMATION 


N-RESET confirm 


essential 


RESTART REQUEST 






RESTART CONFIRMATION 






RESTART INDICATION 


N-DISCONNECT indication 




DIAGNOSTIC 






REGISTRATION REQUEST 






REGISTRATION CONFIRMATION 








N-DATA ACKNOWLEDGE request 


see subclause 24.4.9. 




N-DATA ACKNOWLEDGE indication 


see subclause 24.4.9. 



All the facilities activated by registration cannot be used (no registration primitive). 



The following fields are not used but essential: 

Logical channel identifier, packet type identifier, address length field, facility length field are set by the 
protocol. 

This section lists optional user facilities and DTE facilities. 

They are the only ones handled by the protocol compared to the list defined in ISO 8208 [4]. 
Optional user facilities: 
fast select; 

fast select acceptance; 
throughput class negotiation; 
transit delay selection and indication. 
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Specified DTE facilities: 

called address extension; 

calling address extension; 

end-to-end transit delay negotiation; 

expedited data negotiation; 

basic minimum throughput class negotiation; 

priority. 

24.4.5.2 General operation of the X 25 PLP 1 984 for supporting the OSI CONS 

Applicable to TETRA. 

24.4.6 Network connection establishment phase 
This subclause describes the connection primitives. 

24.4.6.1 Primitive/parameter and packet field relationships 
Applicable to TETRA. 

24.4.6.2 Procedures 

24.4.6.2.1 Primitive and packet mapping 
Applicable to TETRA. 

24.4.6.2.2 NSAP addresses 

This subclause shows how a NSAP address is mapped to and from the address field or the address 
extension facility. Annex F proposes solutions for binding. This is described in ETS 300 392-1 [11], 
clause 7. 

24.4.6.2.3 Receipt confirmation selection 

Applicable to TETRA. 

24.4.6.2.4 Expedited data selection 

Applicable to TETRA. 

24.4.6.2.5 QoS parameter set 

Applicable to TETRA. This is further explained below. 

ISO defines the QoS parameter which corresponds to four parameters: 

throughput from calling to called; 

throughput from called to calling; 

transit delay; 

priority; 
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and for each of these parameters a set of sub-parameters: 
target value; 

lowest quality acceptable value; 
available value; 
selected value. 

ISO defines throughput parameters ranging from 75 bit/s through 19 200 bit/s. 

ISO defines a transit delay parameter ranging from 1 ms to 65 534 ms in increments of 1 ms. The 
unspecified value is allowed. 

24.4.6.2.6 NS user data 

Applicable to TETRA. 

24.4.7 Network connection release phase 

This subclause describes the disconnection primitives. 

24.4.7.1 Primitive/parameter and packet/field relationships 
Applicable to TETRA but new values could be added. 

24.4.7.2 Procedures 

Applicable to TETRA. This is further explained below. 

If an error is detected for which the action is to clear the VC, the layer 3 shall transmit a 
CLEAR REQUEST packet and signal an N-DISCONNECT indication primitive to the user. 

If the layer 3 receives a CLEAR INDICATION packet or a RESTART INDICATION packet, it shall signal it 
by a N-DISCONNECT indication primitive to the user. 

The combination of originator and reason parameters of the N-DISCONNECT primitive is mapped to and 
from the combination of the clearing cause (or restarting cause) and diagnostic cause field. 

24.4.8 Data transfer phase: data transfer service 

This subclause describes the DATA primitives. 

24.4.8.1 Primitive/parameter and packet/field relationship 
Applicable to TETRA. 

24.4.8.2 Procedures 

Applicable to TETRA. This is further explained below. 

The confirmation of receipt can be requested but there is no distinct packet associated with a 
N-DATA ACKNOWLEDGE request and a N-DATA ACKNOWLEDGE indication primitive. 

A N-DATA ACKNOWLEDGE request and indication are introduced to handle the ACK mechanism. 

24.4.9 Data transfer phase: receipt confirmation service 
Applicable to TETRA. 
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24.4.10 Data transfer phase: expedited data transfer service 

Applicable to TETRA. 

24.4.1 1 Data transfer phase: reset service 

Applicable to TETRA. 

24.4.1 2 Response to protocol violation 

Applicable to TETRA. 

24.4.1 3 Conformance 

Applicable to TETRA. 

24.5 Annex A: X25 1980 Sub-network dependant convergence protocol (normative) 

Applicable to TETRA. 

24.6 Annex B: Classification (normative) 

All text referring to "Conforming 1980" and "X25/PLP - 1980" is applicable 
Applicable to TETRA. 

24.7 Annex C: Sub-network convergence protocol for use with X25 permanent virtual circuits 
(normative) 

This annex defines a set of SNDCP procedures for use with X25 Permanent Virtual Circuits (PVC) 
service. The procedures make use of the packets associated with the virtual call service, the images of 
these packets called image packets are encoded within X25 DATA packets. 

Applicable to TETRA. 

24.8 Annex D: Protocol implementation conformance statement proforma (normative) 

Applicable to TETRA. 

24.9 Annex E: Additional considerations of CONS primitives (informative) 

For information. 

24.1 0 Annex F: Use of X25/PLP NPAI (informative) 

For information. 

24.1 1 Annex G: Transit delay calculations (informative) 

For information. 

24.1 2 Annex H: Example of priority negotiation (informative) 

For information. 

24.13 Annex I: Differences between CCITT Recommendation X.223 and ISO 8878 (informative) 

For information. 
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25 CONP protocol (ISO 8208 delta) 

25.1 Introduction 

This clause which describes the connection mode protocol CONP is based on ISO 8208 [4] which 
specifies the procedures, formats and facilities at the packet layer for data terminal equipment based on 
the 1988 CCITT blue book. The standard defines from the viewpoint of the DTE the packet layer which 
governs the transfer of packets at a DTE/DC E or DTE/DTE interface. 

This clause gives the description of the relevant sections of the ISO 8208 [4] which apply to TETRA and 
the specifications. 

It is assumed that the Connection Mode Service (CONS) service description in clause 24 (ISO 8878 delta 
[9]) is applicable first as it defines TETRA CONS, e.g. some X25 packets and facilities have no 
equivalence in CONS. 

This clause describes the air interface protocol and therefore it is assumed that the underlying protocol is 
the MLE. 

25.2 Organisation of this clause 

Subclause 25.4 refers to every clause of the ISO 8208 [4]. The subclauses correspond respectively to the 
clauses of ISO 8208 [4], e.g. subclause 25.4.3. corresponds to ISO 8208 [4], clause 3. For each ISO 8208 
[4] clause, the parts that are relevant to TETRA are listed, and any specific additions or deletions are 
described. Where there are not detailed changes, subclause 25.4 will simply indicate whether the 
ISO 8208 [4] clause applies or not. 

25.3 Overview of the protocol 

25.3.1 Position of the protocol in the network layer 

The architectural organisation of the network layer is described in ETS 300 392-1 [11], clause 6 where at 
layer 3 the connection mode protocol CONP should be used over the MLE (see clause 17). 

25.3.2 Services provided by the protocol 

The CONP protocol shall provide the following services at the TNCO SAP as defined in clause 24: 
virtual call set-up call and clearing; 
data transfer; 
interrupt transfer; 
flow control; 
reset; 
restart. 

The primitives which correspond to the services offered are described in clause 24. 

25.3.3 Underlying services assumed by the protocol 

The underlying services assumed by the protocol are those offered by the MLE (see clause 17). 

25.3.4 Services assumed from the local environment 



None. 
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25.4 ISO 8208 delta 

ISO 8208 [4] gives the X25 procedures and the packets types and formats. As described in 
ETS 300 392-1 [11], clause 12 the CONP PDUs are the packets defined in ISO 8208 [4] conforming to 
clause 24. The following subclause refers to ISO 8208 [4] which includes addressing. 

The PDUs are either built by CONP from the CONP primitives and its parameters or generated internally 
as a result of packet exchange received at the LCO SAP not visible at the TNCO SAP. 

25.4.1 Scope 
Applies to TETRA. 

25.4.2 Normative references 

A correspondence shall be ensured between the different versions of documents belonging to ISO and 
also CCITT. (The CCITT documents are issued first followed by the corresponding ISO document). 

The ISO 8878 [9] which is the use of X25 to provide the OSI connection mode network service is based 
on the document ISO 8208 [4] which is the X25 packet layer protocol for data terminal equipment. 

Table 351 shows the combinations limited to the ISO combinations. 



Table 351: Document correspondence 



TETRA reference 


ISO 8878 [9] version 
(CONS ) 


ISO 8208 [4] 
version (X25) 


Action 


XXXXXXXXXXXXXX 


1987 version 
based on > 


1980 version 


considered in this 
clause 


XXXXXXXXXXXXXX 


1987 version 
based on > 


1984 version 


Considered in this 
clause 


ISO 8208 delta 


1987 version 


1990 version 
(based on CCITT 
ver 1984 then 
1988) 

< refers 

to 




ISO 8878 delta [9] 


1992 version 
based on > 


1990 version 





This clause is based on the ISO 8208 [4] which refers to ISO 8878 [9]. 
25.4.3 General considerations 

The ISO 8208 [4] is based on the 1988 CCITT book but it contains the necessary provisions for 
compatibility with the previous versions of X25 1984 and 1980, the major technical differences being: 

NUI (Network User Identification) related facilities; 

RPOA (Recognised Private Operating Agencies ) related facilities; 

call redirection and call deflection related facilities: 

call deflection and Network User identification (NUI) override were not defined; 

NUI and RPOA facilities were not explicitly separated into subscription and negotiation 
facilities; 

priority and protection DTE facilities; 

coding of called and calling address extension has changed as only BCD was allowed. 
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The protocol sequences and associated PDUs shall be as shown in figure 158 to figure 161 inclusive. 
25.4.4 Procedures for restart 

Only the restart procedures defined in clause 24 shall apply to TETRA. 
The PDU shall correspond to restart indication packet. 
This is illustrated as follows: 

Al TETRA infrastructure Al 



MS 

CONP MLE 



TETRA infrastructure 

CONP MLE MLE CONP 



MS 

MLE CONP 



N-RESET request 



N-RESET confirm 



MLE-l|)NITDATA request 
<reset request> 



MLE-UNITDATA request 



<restart request> 



<restart indication 



<reset indication> 



<restart confirm> 



N-RESET indication 
N-RESET response 



N-RESTART indication 

-> 



Figure 158: Reset and restart protocol sequence 
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25.4.5 



Procedures for virtual call set-up and clearing 



The PDUs shall correspond to call request, incoming call, call accepted, call connected, clear request and 
clear indication packets. 

Applicable to TETRA according to clause 24. 

This is illustrated as follows: 



MS 

CONP MLE 



Al 



TETRA infrastructure 

CONP MLE MLE CONP 



Al 



MS 

MLE CONP 



\ 



/ 



N-CONNECT 
request 



N-CONNECT 
confirm 



N-DISCONNECf 
request 



MLE^j JNITDATA request 



<call request> 



<clear request> 



MLE-U ^ITDATA indication 



incoming call> 



MLE-UNITDATA in( icatii 



<clear request> 



<dear confirm> 



icatidn 



CONNECT indication 
rfCONNECT response 



N-DISCONNECT 
indication 



Figure 159: Connection and disconnection protocol sequence 



Page 533 
ETS 300 392-2: March 1996 



25.4.6 Procedures for data and interrupt transfer 

Delivery confirmation D bit shall be applicable. 

Data mark M bit shall be applicable. 

See clause 24 for applicable procedures. 

The PDUs shall correspond to data and Interrupt packets. 

This is illustrated as follows: 

Af 



MS 

CONP MLE 



TETRA infrastructure 

CONP MLE MLE CONP 



Al 



MS 

MLE CONP 



N-DATA request 



request 



MLE-UNITDATA request 



/ 



<- 

MLE-I 



<data> 



MLE-F EPORT indication 



MLE- JNITDATA request 



<interrupt> 
FlEPORT indication 



<data> 
MLE-UNITDATA inc 



icatidn 



<interrupt> 



MLE-UNITDATA inc 



icatidn 



N-DATA indication 



N-EXPEDITED DATA 
indication 



25.4.7 



Figure 160: Data and interrupt transfer protocol sequence 
Procedures for flow control 



The procedures for flow control apply to TETRA with packet sequence numbers received and sent P(R) 
and P(S) and window. 

25.4.8 Procedures for reset 

Applicable to TETRA according to clause 24. 

The PDUs shall correspond to the reset request, reset indication, reset confirm, reset response packets. 

25.4.9 Effects of clear, reset, restart procedures on the transfer of packets 
Applicable to TETRA according to clause 24. 

25.4.10 Effects of layer 1 and 2 on the packet layer 
Not applicable to TETRA. 

Changes of operational states shall be indicated by use of restart, clear or reset procedures as defined in 
clause 24. 

Provision for the underlying protocol is described in later subclauses. 

25.4.1 1 Error handling 

Applicable to TETRA except the diagnostic packet as defined in clause 24. 
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25.4.12 Packet format 

Applicable to TETRA according to clause 24. 

25.4.1 3 Procedures for optional user facilities 

Applicable for TETRA for the optional user facilities according to clause 24. 

25.4.14 Procedures for optional CCITT specified DTE facilities 

Applicable for TETRA for the optional CCITT specified DTE facilities described in clause 24. 

25.4.1 5 Format for facility field in call set-up clearing packets 
Applicable to TETRA for the optional user facilities described in clause 24. 

25.4.16 Format for registration field in registration packets 
Not applicable to TETRA. 

25.4.1 7 Diagnostic codes 

Applicable to TETRA for the corresponding packet types. 

25.4.18 Timers and re-transmission counts 
Applicable to TETRA according to clause 24. 

25.4.1 9 State diagrams 

Applicable to TETRA according to clause 24. 

25.4.20 State tables 

Applicable to TETRA according to clause 24. 

25.4.21 Annex A: Private networks 

This covers a DTE which is a private network accessing a public network DCE. 
Not applicable to TETRA as this ETS relates to the air interface. 

25.4.22 Annex B: Differences between the first and the second editions of ISO IEC 8208 

For information. 

25.4.23 Amendment 1 : Alternative logical channel identifier assignment 

Not applicable to TETRA. 
25.5 Protocol functions 

The protocol functions shall be (clause 24): 

message segmentation re-assembly: the messages sent by the application may be eventually 
segmented in packets in three user data fields of 4 096 bytes maximum, the standard default value 
being 128 bytes user data. The packet header shall be 3 or 4 bytes depending whether packet 
sequence numbering is performed modulo 8 or modulo 128. Packets may be eventually 
reassembled (sequence number) before being delivered to the application; 



Page 535 
ETS 300 392-2: March 1996 

packet composition and decomposition: each type of packet is built from the primitive type and the 
primitive parameters. The logical channel identifier, packet type identifier, packet length field and 
facility length field shall be added. 

Some packets noted as essential are built internally to follow the standard X25 procedures as defined in 
clause 24: 

receipt confirmation selection: this function shall correspond to confirmation if requested; 

expedited data selection: this function shall correspond to a facility to use the expedited data 
negotiation facility in some packets; 

QoS parameters check and processing: this function shall correspond to throughput class 
negotiation and transit delay selection and indication; 

error detection and handling: this function shall correspond to an unexpected packet or when a 
packet with an error in the parameters is received, a packet is out of sequence, a protocol error; 

fast select and fast select acceptance handling: this function authorises some packet types to 
contain a call user data field; 

flow control: the transmission shall be controlled separately for each direction and is based on 
authorisations from the receiver. A sequence numbering of data packets shall be performed. A 
window mechanism shall be defined as the ordered set of N set of N consecutive packet send 
sequence numbers P(S) of the data packets authorised to cross the interface. A delivery 
confirmation is also dealt by this function; 

reset: several actions shall be taken to remove the transmitted packets from the window, the lower 
window edge is set to zero, timers are set back to their initial value. 

25.6 Provision of the underlying protocol 

25.6.1 Mapping of the primitives 

The CONP should be capable of operating over the MLE as defined in clause 17 which manages the radio 
resources, the radio link and the identities. 

The underlying services at the LCO SAP should be: 

for data transf e r acknowledged : 

MLE-UNITDATA request/indication; 

MLE-REPORT indication. 

for access to resources indication: MLE-OPEN indication. 

All PVC are reset. 

indication of the non access to the resources: MLE-CLOSE indication. 

All virtual calls are cleared and all PVCs are cleared. 

reset: MLE-RESET request/indication/confirm/response; 

indication of temporary unavailability of underlying service and resumption of underlying service: 
MLE-BREAK indication; 
MLE-RESUME indication. 
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This is illustrated as follows: 
MS 



SwMI 



CONP 



MLE 



MLE- O^EN 



MLE-CLOSE 



MLE-RESET request 



/ 



MLE-RESET confirm 



LLC 



CONP 



MLE 



LLC 



T L-CONNEC T request 



TL-CONNECT indication 



MLE-RESET indication 

I 

MLE-RESET response 



\ 



TL-CONNECT response 



TL-CONNECT confirm 



Figure 161 : Access to resources and reset protocol sequence 
25.6.2 Mapping of QoS 

Only mapping of priority is done on the air interface as defined in quality of service. 

26 Specific Connectionless Network Service (SCLNS) description 

26.1 Introduction 

This clause describes the connectionless mode service provided by the network layer (TETRA layer 3) to 
the higher layers. Normally the service user will be the transport layer, but a further convergence sub-layer 
may be included between this service boundary and the transport layer as described in the technical 
realisation in ETS 300 392-1 [11], clause 13. 



The underlying protocol used to provide this connectionless service is assumed to be the TETRA specific 
connectionless protocol (SCLNP), see clause 27. This may use any suitable layer 2 services, as described 
in the technical realisation in ETS 300 392-1 [1 1 ], clause 1 3. 

There is no conformance of equipment to this clause. Instead, conformance shall be achieved through 
implementations of the assumed SCLNP. Nevertheless this clause is intended to provide the basis for the 
definition of a conformant service boundary (e.g. an API). 

This service is described in terms of SAPs and primitives. 

26.1 .1 Specific connectionless service 

This service shall be based on the ISO connectionless mode principles. The service boundary shall 
correspond to the top of the lowest network sub-layer, the sub-network access role, as defined in ISO 
8648 [8]. This TETRA specific connectionless mode transmission service shall be designed to be used as 
the sub-network service in the following configurations: 

a) a sub-network service that can support the requirements of the ISO connectionless protocol 
(ISO-CLNP) with a convergence protocol; 



b) a sub-network service that can be used directly to support specific higher layer protocols (e.g. a 
specific transport layer protocol, or a specific mobile application); 



Page 537 
ETS 300 392-2: March 1996 



c) a sub-network service that can support the requirements of the Internet Protocol (IP) with the 
addition of a suitable convergence protocol. 

These configurations are illustrated as follows: 

(a) Support for (b) Support for (c) Support for 

ISO CLNP Specific user convergence to IP 

subnetwork I I I 



independent 


ISO-CLNP 




Null 




IP 


functions 













dependent 


convergence 




Null 




convergence 




functions 














subnetwork 














access 


SCLNP 




SCLNP 




SCLNP 





Figure 162: Alternative network layer configurations 

This TETRA specific connectionless service shall incorporate additional facilities compared to the ISO 
network service described in ISO 8348/Addendum 1 [5]. These facilities are included to provide increased 
functionality in a mobile packet data environment. A so-called "SLIM" subset of the service is defined for 
those users who do not wish to take advantage of these additional facilities: this subset corresponds most 
closely to the ISO service definition. 

26.1 .2 ISO principles of connectionless mode transmission 

This standard uses the concept of connectionless mode transmission as defined in IS0.7498/Add 1 [3]. 
Connectionless mode transmission is the transmission of a single unit of data from a source SAP to one 
or more destination SAPs without establishing a connection. A connectionless mode service shall allow an 
entity to initiate such a transmission by performing a single service access. 

An instance of the use of a connectionless mode service does not have a clearly distinguished lifetime. In 
addition, the connectionless mode service shall have the following fundamental characteristics: 

a) it requires only a pre-existing association between the peer entities involved, which determines the 
characteristics of the data to be transmitted, and a two-party agreement between each peer-entity 
and the next lower layer. No dynamic peer-to-peer agreement is involved in an instance of the use 
of the service; 

b) all of the information required to deliver a unit of data is presented to the layer providing the 
connectionless mode service, together with the user data to be transmitted as a single service 
access (i.e. using a set of parameters in a single service primitive). The connectionless mode 
service provider is not required to relate a given service access to any other service access. 

Connectionless mode transmission creates no relationship between service data units. A series of service 
data units supplied in a particular sequence to the service provider will not necessarily be delivered to the 
destination(s) in the same order. Instances of service failure (failure to deliver) will not necessarily be 
reported. 

26.1.3 General principles 

In order to initiate a connectionless mode service access, there must be a pre-arranged association 
between service users. This refers to the a priori knowledge that each service user must have. This 
association is not described in this standard and it comprises the following elements: 

a) knowledge of the addresses of the peer entities; 
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b) knowledge of a protocol agreed by the peer-entities for use at least for initial communication; 

c) knowledge of the probable availability of the peer-entities for communication (see note); 

d) knowledge of the quality of service on offer from the network service. 

NOTE: This refers to the general availability of the peer-users, and not the short term 
unavailability caused by radio outage. 

These associations are required to allow correct routing of the service data units by the service provider 
and correct interpretation of the service data units by the destination user. 

26.1 .4 Sub-addresses 

Certain sub-addresses are reserved for ISO-CLNP and IP convergence (see clause 27). 
26.2 SCLNS service description 
26.2.1 SAP 

SCLNP shall provide services to the application through one SAP. This relationship is shown as follows: 



Higher Layer 

endpoint ^ 





TN-SCLNS SAP 









SCLNP 



Figure 163: SAP between higher layer and SCLNP 

Each independent instance of service shall be represented by a single service endpoint, corresponding to 
a single value of ITSI. 

NOTE: The SCLNS includes a sub-address field that can be used to enable several service 
users to share this single endpoint. 

26.2.2 Services available at the TN-SCLNS-SAP 

The data transfer services shall provide the means whereby network Service Data Units (SDUs) are 
delimited and transparently transmitted from a source NSAP to a destination NSAP in a single 
connectionless mode service access. The maximum size of a connectionless mode SDU is defined in 
subclause 26.2.3.1. 

Certain measures of quality are associated with each instance of connectionless mode transmission, as 
defined in ETS 300 392-1 [1 1]. In addition, certain user defined facilities may be specified when using the 
FULL service. All of these parameters shall be agreed between the network service provider and the 
sending user when a connectionless mode transmission is initiated. 

All data transfers require both a source and destination address. The source address shall always be an 
individual TETRA address, but the destination address may be either an individual TETRA address or a 
group TETRA address. 

The point-to-point service shall provide a connectionless mode transmission between one source MS and 
one destination MS or LS. 

The point-to-multipoint services shall provide a connectionless mode transmission between one source 
MS or LS and one group of MSs and LSs. 
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26.2.3 Full and slim services 

This connectionless mode service mode shall be operated in the following modes: 

a) the FULL service, which provides data transfer plus all of the TETRA specific facilities as defined in 
this subclause; 

b) a SLIM subset of the service which provides data transfer, but only provides a few of the facilities 
defined in this subclause. 

26.2.3.1 Data transfer service 

The data transfer shall provide a connectionless mode service that is the same for both the FULL service 
and the SLIM subset. It shall support both sending and receiving of data without connection 
establishment. 

The maximum NSDU length shall be 2 048 bytes of user data. 

NOTE 1: This service offers a sub-network service that is fully compatible with the sub-network 
requirements of ISO CLNP.[6], ISO CLNP requires a minimum SDU of 512 bytes. 

The data transfer service should be invoked with a TN-UNITDATA request primitive. The TN-UNITDATA 
confirm should provide a confirmation of a successful start to the data transfer. 

NOTE 2: This infrastructure confirmation only reports success for the first data link. More 
detailed reports are provided as part of the FULL service with the TN-DELIVERY 
indication primitives. 

26.2.3.2 Facilities provided by the service 

The following facilities are essential, and shall be provided by both the full and slim protocol: 

a) priority; 

b) sub-addressing. 

The following facilities are additional, and shall only be provided by the full protocol with a defined level of 
function: 

c) delivery disposition; 

d) time stamping. 

The following facilities shall be provided by the full protocol, but the level of support shall be defined by the 
network operator: 

e) multicast; 

f) area selection; 

g) packet storage. 

The details of the additional facilities offered by a given network can be negotiated and examined using 
the facility negotiation primitives. 
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26.3 Primitive definitions 

26.3.1 Primitives types 

Four different types of primitives should be used: 

request: for the higher layer to request service from the lower layer; 

confirm: for the lower layer providing the service to confirm that the activity has been completed; 

indication: for the lower layer to notify the next higher layer of any specific service related activity; 

response: for the higher layer to acknowledge receipt of an indication primitive from the next lower 
layer. 

In this clause the term "higher layer" shall refer to the transport layer, and the term "lower layer" shall refer 
to the MLE. 

26.3.2 Data transfer primitives 

The data transmission primitives should include the following types: 
TN-UNITDATA request; 
TN-UNITDATA indication; 
TN-UNITDATA confirm; 
TN-DELIVERY indication. 

The TN-UNITDATA primitives should be used for unidirectional connectionless mode transfer. Each 
sequence of TN-UNITDATA primitives conveys a single network service data unit (NSDU) from one 
source user to one or more destination users. Each NSDU is independent in the sense that the NS 
provider is not required to maintain any relationship between this NSDU and any other NSDU. Each 
TN-UNITDATA primitive is self contained in the sense that all of the information required to deliver the 
NSDU is presented to the NS provider, together with the user data to be transmitted, in a single service 
access. 

TN-UNITDATA request: this primitive should be used by the sending user to initiate a connectionless 
mode transmission. This primitive also allows the user to select the facilities and quality of service 
parameters that shall apply to this packet. 

TN-UNITDATA indication: this primitive should be used to deliver one NSDU to the destination user(s). 
This primitive also contains facilities that are delivered to the destination user(s). 

TN-UNITDATA confirm: this primitive should be the immediate response to each TN-UNITDATA request 
from the infrastructure. It only confirms the successful transfer of the NSDU to the infrastructure. 

Following successful initiation of a connectionless mode transmission, one or more delivery disposition 
reports may be returned by the infrastructure, if requested with the delivery disposition facility. Each of 
these reports is delivered independently to the sending user with a TN-DELIVERY indication primitive. 
Each primitive corresponds to the receipt of one report. 

TN-DELIVERY indication: should be used to supply one delivery disposition report to the sending user. 
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26.3.3 Sequence of data transfer primitives 

TN-UNITDATA 




TN-UNITDATA 
confirm 



Figure 164: Sequence of primitives for basic data transfer 




TN-DELIVERY 
indication 



Figure 165: Sequence of primitives for delivery report 
26.3.4 Contents of primitives 

These layer 3 primitives are defined only for the purpose of describing the layer-to-layer interactions. Each 
primitive is described as an abstract list of parameters and their concrete realisation may vary between 
implementations. This ETS does not define a concrete structure for these primitives and no formal testing 
of primitives is intended. 

NOTE: In order to define a conformant service, the primitive parameters should be 
implemented to accommodate all applicable values of the corresponding PDU fields as 
defined in SCLNP (see clause 270. 

26.3.4.1 Parameter definitions 

The following definitions apply to all of the primitives. Definitions appear in alphabetic order. 

Destination address: the value of ISSI or GSSI to be used for this transmission (see ETS 300 392-1 [11], 
clause 7. 

Facilities: the values of all the facilities that should be used (see subclause 26.2.3.2). 

Network Service Data Unit (NSDU): the higher layer information that is to be transported. 

NOTE: The operations across the service boundary are such that the layer sending the 
message to its peer can assume a temporal order of bits within the SDU and the 
(peer) layer receiving the primitive can reconstruct the message with its assumed 
temporal order. 

Network Service Data Unit Length (NSDU length): the length of the higher layer information. The 
coding of this parameter shall be a local matter and are not defined in this ETS. 

Protocol subset: the subset of the protocol that shall be used: FULL or SLIM. 

QoS: the quality of service parameters as defined in ETS 300 392-1 [11]. 

Report: the report indicates the success or failure of a data transmission. 
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Source address: the value of ISSI to be used for this transmission (see ETS 300 392-1 [11], clause 7). 
26.3.4.2 TN-UNITDATA primitives 



Table 352: TN-UNITDATA primitives 



Parameter 


Request 


Confirm 


Indication 


DESTINATION ADDRESS 


M 


(=) 


(=) 


SOURCE ADDRESS (note 3) 


- 


- 


M 


PROTOCOL SUBSET 


M 


(=) 


(=) 


REPORT 




M 




QoS 


M 


(=) 


(=) 


NSDU 


C 




C(=) 


NSDU LENGTH 


C 




C(=) 


FACILITIES (notes 1 and 2) 








Area Selection 


c 


(=) 


(=) 


Delivery/Store request 


c 


(=) 


(=) 


Multicast 


c 


(=) 


(=) 


Packet storage 


c 


(=) 


(=) 


Priority 


M 


(=) 


(=) 


Sub-address 


M 


(=) 


(=) 


Timestamp (note 4) 






c 


NOTE 1 : The facility parameters, except priority and sub-address, only apply 

when using the FULL service and shall be omitted when using the SLIM 

service. Refer to subclause 26.2.3.2. 
NOTE 2: The essential facilities shall always contain valid information. The 

additional facilities shall always appear in the primitives but may contain 

invalid information. 

NOTE 3: The source address is implicit in the request and confirm primitives, 
since a single instance of SCLNP is bound to one value of ITSI. 

NOTE 4: The timestamp is added by the infrastructure. Therefore it only appears 
in the indication primitive. 



KEY: M: Mandatory; C: Conditional; (=): Equal to corresponding primitive; -: Not used 
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26.3.4.3 TN-DELIVERY primitives 



Table 353: TN-DELIVERY primitives 



Parameter 


Indication 


DESTINATION ADDRESS (notes 1 and 2) 


M 


SOURCE ADDRESS (notes 1 , 2 and 4) 




NSDU (note5) 


C 


NSDU LENGTH (note 5) 


C 


FACILITIES (note 3) 




Delivery/Store request 


M 


Disposition Report 


M 


Multicast 


M 


Priority 


M 


Sub-address 


M 


Timestamp 


M 


NOTE 1: These mandatory parameters are equal to the parameters in 
the corresponding TN-UNITDATA request primitive. 

NOTE 2: The destination address and source address will be reversed 
relative to the corresponding TN-UNITDATA request. 

NOTE 3: Some of the facility parameters may contain null information 
in certain cases. 

NOTE 4: The source address is implicit in the indication primitive, since 
a single instance of SCLNP is bound to one value of ITSI. 

NOTE 5: The NSDU has a maximum length of 2 octets. The NSDU 
contains the two first octets of the original SDU. This permits 
a user application to distinguish uniquely between up to 
65 536 transmitted SDUs if required. 



KEY: M: Mandatory; C: Conditional; (=): Equal to corresponding primitive; -: Not used 



26.3.5 State description 



TN-UNITDATA request 
TN-UNITDATA confirm 
TN-UNITDATA indication 
TN-DELIVERY indication 




Figure 166: State transition diagram 



The IDLE state represents the initial and final state of all the primitive sequences. 



27 Protocol for providing the SCLNS 



27.1 Introduction 



This clause defines the TETRA Specific Connectionless Protocol (SCLNP). This is the network layer 
protocol that shall be used to provide the Specific Connectionless Network Service (SCLNS) as defined in 
clause 26. This clause defines the protocol functions required for operation as an end system (i.e. 
providing service to an end user) or as an intermediate system (e.g. as a network layer relay). 
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This clause specifies: 

procedures for the specific connectionless transmission of data and control information from one 
network entity to a peer network entity; 

the functional requirements for implementations claiming conformance to this ETS; 

the encoding of the protocol data units (PDUs) used for the transmission of data and control 
information; 

procedures for the correct interpretation of protocol control information. 
The procedures are defined in terms of: 

interactions among peer network entities through the exchange of PDUs; 

interactions between a network entity and a network service user through the exchange of network 
service primitives; 

interaction between a network entity and an underlying service provider through the exchange of 
service primitives. 

For the definitions related to the reference model this clause makes use of the terms defined in ISO 7498 
[3] and ETS 300 392-1 [1 1], clause 5. 

For the definitions related to the service convention this clause makes use of the terms used in 
ISO TR 8509 [7]. 

For the definitions related to the network layer architecture this clause makes use of the terms used in 
ISO 8648 [8] and ETS 300 392-1 [1 1], clause 6. 

For the definitions related to the network layer addressing this clause makes use of the terms used in 
ISO 8348 [5] and ETS 300 392-1 [11], clause 7. 

27.2 Overview of the protocol 

27.2.1 Position of the protocol in the network layer 

The internal organisation of the network layer is described in ETS 300 392-1 [11], clause 6. This is closely 
based on the ISO 8648 [8] definition. 

The Specific Connectionless Network Protocol (SCLNP) is designed to be used in the lower sub-layer of 
the network layer, in the role of a sub-network access protocol. A protocol which fulfils this role operates 
under constraints that are stated explicitly as characteristics of a specific sub-network. The operation of 
such a protocol contributes to the provision of a sub-network service which is specific to the sub-network 
concerned; this sub-network service may or may not coincide with the OS! network service. 

Within a given sub-network there may be relaying and routing functions which govern the forwarding of 
information entirely within the sub-network itself. These relaying and routing functions are associated with 
the operation of this sub-network access protocol. These relaying and routing functions may extend 
across the addressing domain of all TETRA systems, but they are not intended to be applied outside of 
that domain. 

The operation of this protocol is specified with respect to an underlying service which is made available 
through the operation of other network layer protocols or through the provision of a layer 2 service. The 
alternative underlying services assumed by this protocol are described in subclause 27.2.5.. 

27.2.2 Slim subset of the protocol 

One subset of the full protocol is defined. This is the "slim" subset which provides a reduced service that 
does not provide all of the facilities. This permits a shorter protocol data unit header to be used for the air 
interface when it is known that these facilities are not required. 
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NOTE: The remaining facilities may not be selected individually. The Full protocol provides all 
facilities and the Slim subset provides a few of them. 

27.2.3 Addresses 

The "source address" and "destination address" parameters referred to in this ETS are TETRA subscriber 
addresses (TSI), or short subscriber addresses as described in ETS 300 392-1 (1 1], clause 7. 

Two formats of addresses shall be used in the air interface PDUs: 

a) short addresses, based on SSI; 

b) long addresses, based on complete TSI. 

Short addresses allow shorter PDU headers to be used, giving more protocol efficiency, for intra-TETRA 
calls, i.e. source and destination both in the same TETRA network. 

Only the long format of address based on TSIs is used in the intersystem PDUs. 

27.2.4 Services provided by the protocol 

This protocol provides the TETRA specific connectionless mode network service at the SCLNS SAP as 
described in clause 26. 

The services offered are: 

a) data transfer; 

b) facilities. 

27.2.4.1 Data transfer service 

The data transfer service shall be the same for both the full protocol and the slim subset. It shall support 
sending of user data without connection establishment. The user data shall be restricted to a maximum 
length of 2 048 bytes of user data. No segmentation is provided. 

NOTE 1 : This service offers a sub-network service that is fully compatible with the sub-network 
requirements of ISO CLNP [6], ISO CLNP requires a minimum SDU of 512 bytes. 

The data transfer protocol shall provide a confirmation of uplink success of data transfer. 

NOTE 2: This confirmation only reports success or failure for the first hop, i.e. for the packet 
transfer to the infrastructure. More detailed reports are also available using the delivery 
disposition facility. None of these reports provides a end-to-end confirmation from the 
peer user, i.e. from the destination. 

27.2.4.2 Facilities 

The following facilities are essential, and shall be provided by both the slim and the full protocol: 

a) priority; 

b) sub-addressing. 

The following facilities are additional, and shall be provided by the full protocol: 

c) delivery disposition; 

d) time stamping. 
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The following additional facilities shall be provided by the full protocol, but this ETS does not specify the 
level of infrastructure provision, i.e. the allowed values may be restricted by a given implementation: 

e) multicast; 

f) area selection; 

g) packet storage. 

NOTE: The structure of the full PDUs is the same, irrespective of the level of provision of a 
facility. Fields that correspond to non-supported additional facilities are ignored. 

27.2.5 Underlying services assumed by the protocol 

For the air interface, the protocol operation should be defined to use the MLE underlying service as 
described in clause 17. This type of operation shall be used for either MS or BS operation. 

On a LS the underlying protocol can be either a convergence sub-layer, e.g. an equivalent line link entity, 
or direct mapping to a suitable layer 2 protocol. A TETRA network operator may also provide a CONS 
gateway into SCLNP. 

For internal infrastructure operations, no specific underlying sen/ice is defined in this ETS. 

To allow consideration of all these different cases the protocol operation is defined in subclause 27.8 with 
respect to an abstract underlying service. This underlying service consists of a single TSN-UNITDATA 
primitive which conveys the source and destination sub-network point of attachment addresses, sub- 
network quality of service parameters, and all of the octets of user data. 

The TSN-UNITDATA primitive should only be used to describe the abstract interface between this 
protocol and either a real underlying sub-network or convergence sub-layer which operates over a real 
data link to provide the required service. 

Provision of these alternative underlying services is described in subclause 27.8. 

27.2.6 One instance of protocol 

A single instance of SCLNP is defined by the addresses. One instance of a sending or receiving protocol 
corresponds to one family of TETRA addresses as defined in ETS 300 392-1 [11], clause 7. An instance 
of protocol only exists when the protocol has been bound to a valid ITSI address. 

An instance of sending or receiving protocol may be removed or created at any time according to this 
definition. For example, in an MS, the binding of addresses is controlled by the mobile link entity, and an 
instance shall only be considered to exist when this binding is completed and access to underlying 
services has been provided (see subclause 27.8). 

27.2.7 Service assumed from the local environment 

A timer service shall be provided by the LLME to allow the protocol entity to schedule events. 

There are three primitives associated with the timer service: 

S-TIMER request primitive which indicates to the local environment that it should initiate a timer of 
the specified name and maintain it for the duration specified by the time parameter; 

S-TIMER response primitive which is initiated by the local environment to indicate that the amount 
of time requested by the corresponding S-TIMER request has elapsed; 

S-TIMER cancel primitive which is an indication to the local environment that the specified timer 
should be cancelled. 

The "S-Time" parameter indicates the time duration of the specified timer. 
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27.3 Overview of the PDU structures 



This subclause gives a summary of the structure of the SCLNP-PDUs. Different PDU structures are 
defined for the air interface and the intersystem interface as described in ETS 300 392-1 [11], clause 13. 

Each type of PDU shall be defined in each of the following structures: 

<S1 -XXX> PDU, for the air interface uplink; 

<S2-XXX> PDU, for the air interface downlink; 

<S3-XXX> PDU, for the intersystem interface. 
This different structures are defined to allow the air interface PDUs to as short as possible. 
Table 354 shows all the different PDU combinations. 

Table 354: PDU combinations 





PDU structure 


Options allowed 
(see note) 


DATA 




Uplink 


Downlink 


ISI 


Address: 
Short (S) 
Long (L) 


Facilities: 
Full (F) 
Slim (S) 


Content 


DATA 


<S1-DT> 


<S2-DT> 


<S3-DT> 


S,L 


F.S 


User Data 


DELIVERY 




<S2-DEL> 


<S3-DEL> 


S,L 


F 


None 


NOTE: These options only apply to the uplink and downlink PDUs. Intersystem Interface (ISI) PDUs 
always use long addresses and full facilities. 



27.4 PDU descriptions 
27.4.1 General format 

The general basic format of the SCLNS PDU shall be according to table 355 

Table 355: Format of SCLNS PDU 



PDU header 
Data Part 


Fixed Part 


Address Part 


Facilities Part 


Header Checksum (see note) 
User Data 


NOTE: The header checksum only appears in intersystem PDUs. 



The total size of the PDU header is variable. Both the address part and the facility part can have different 
lengths: 



fixed part: 
address part: 



3 octets; 
3 or 6 octets; 



short addresses: 3 octets; 
long address: 6 octets; 



facility part: 



slim subset: 
full protocol: 



0 or N octets; 
0 octets; 

N octets (see note). 



NOTE: The length of the facility part (N) is only dependant on the PDU type and structure. N is 
constant for a given PDU type and structure. 
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Header checksum: 2 octets 
Table 356 gives a detailed view of the contents of different types of PDU at the air interface: 



Table 356: Contents of air interface PDUs 





FIELD 


S1-DT PDU 


S2-DT PDU 


S1-DEL PDU 


S2-DEL PDU 




Version 


X 


X 




X 


FIXED 


Type 


X 


X 




X 


PART 


Flags 


X 


X 




X 




Priority 


X 


X 




X 




Sub-address 


X 


X 




X 




Packet Length 


X 


X 




X 


ADDRESS 


Destination Address 


X 






X 


PART 


Source Address 




X 




X 




Del/Storage 
Request 


X 


X 




X 


FACILITY 


Rep Request 


X 


X 




X 


PART 


Timestamp 


X 


X 




X 




Multicast area 
selection 


X 










Disposition Report 








X 


DATA 












PART 


User Data 


X 


X 




X 


NOTE: Only part of the user data is returned in the delivery PDU. 



27.4.2 <S1-DT>and <S2-DT> PDU headers with short address 



<S1-DT>PDU HEADER <S2-DT>PDU HEADER 



(Uplink PDU) 


octet 


(Downlink PDU) 


Version 


PDU Type 


1 


Version 


PDU Type 


Flags 


Packet Length 


2 


Flags 


Packet Length 


Sub-address 


Priority 


3 


Sub-address 


Priority 


Packet Length 


4 


Packet Length 


Destination Address 


5 


Source Address 


Destination Address 


6 


Source Address 


Destination Address 


7 


Source Address 


Facility 


part (full protocol only) 


Timestamp 


8 


Timestamp 


Timestamp 


9 


Timestamp 


Timestamp 


10 


Timestamp 


D/S request 


Rep request 


11 


D/S request 


Rep request 


Multicast Area Selection 


12 


Reserved 



NOTE: The MLE sub-layer adds a source address parameter to the uplink PDU and adds a 
destination address parameter to the downlink PDU. Thus both source and destination 
addresses are available to layer 3. 



Figure 167: <S1-DT> and <S2-DT> PDU headers with short address 
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27.4.3 <S1-DT>and <S2-DT> PDU headers with long address 

<S1-DT>PDU HEADER <S2-DT>PDU HEADER 



(Uplink PDU) 


octet 


(Downlink PDU) 


Version 


PDU Type 


1 


Version 


PDU Type 


Flags 


Packet Length 


2 


Flags 


Packet Length 


Sub-address 


Priority 


3 


Sub-address 


Priority 


Packet Length 


4 


Packet Length 


Destination Address 


5 


Source Address 


Destination Address 


6 


Source Address 


Destination Address 


7 


Source Address 


Destination Address 


8 


Source Address 


Destination Address 


9 


Source Address 


Destination Address 


10 


Source Address 


Facility 


Dart (full protocol only) 


Timestamp 


11 


Timestamp 


Timestamp 


12 


Timestamp 


Timestamp 


13 


Timestamp 


D/S reguest 


i Rep reguest 


14 


D/S reguest 


Rep reguest 


Multicast Area Selection 


15 


Reserved 



NOTE: The MLE sub-layer adds a source address parameter to the uplink PDU and adds a 
destination address parameter to the downlink PDU. Thus both source and destination 
addresses are available to layer 3. 

Figure 168: <S1-DT> and <S2-DT> PDU headers with long address 

27.4.4 <S3-DT> PDU header 

<S3-DT>PDU HEADER 



(Intersystem PDU) 


octet 


Version 


PDU Type 


1 


Flags 


Packet Length 


2 


Sub-address 


Priority 


3 


Packet Length 


4 


Source Address 


5 


Source Address 


6 


Source Address 


7 


Source Address 


8 


Source Address 


9 


Source Address 


10 


Destination Address 


11 


Destination Address 


12 


Destination Address 


13 


Destination Address 


14 


Destination Address 


15 


Destination Address 


16 


Timestamp 


17 


Timestamp 


18 


Timestamp 


19 


D/S reguest 


I Rep reguest 


20 


Multicast Area Selection 


21 


Packet Route 


22 


Header checksum 


23 


Header checksum 


24 



Figure 169: <S3-DT> PDU header 
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27.4.5 



<S2-DEL> PDU header with short address 



octet 
1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 



<S2-DEL>PDU HEADER 
(Downlink PDU) 



Version 



Flags 



Sub-address 



PDU Type 



Packet Length 



Packet Length 



Priority 



Source Address 



Source Address 



Source Address 



Timestamp 



Timestamp 



Timestamp 



D/S request | Rep request 



Disposition 



Figure 170: <S2-DEL> PDU header with short address 



27.4.6 <S2-DEL> PDU header with long address 



octet 

1 
2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 



<S2-DEL>PDU HEADER 
(Downlink PDU) 



Version 



Rags 



Sub-address 



PDU Type 



Packet Length 



Packet Length 



Priority 



Source Address 



Source Address 



Source Address 



Source Address 



Source Address 



Source Address 



Timestamp 



Timestamp 



Timestamp 



D/S request | Rep request 



Disposition 



Figure 171: <S1-DEL> PDU header with long address 



27.4.7 



<S3-DEL> PDU header 
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<S3-DEL> PDU HEADER 
(Intersystem PDU) 



Version 



Flags 



Sub-address 



PDU Type 



Packet Length 



Packet Length 



Priority 



Source Address 



Source Address 



Source Address 



Source Address 



Source Address 



Source Address 



Destination Address 



Destination Address 



Destination Address 



Destination Address 



Destination Address 



Destination Address 



Timestamp 



Timestamp 



Timestamp 



D/S request | Rep reguest 



Disposition 



Packet Route 



Header checksum 



Header checksum 



octet 
1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 



Figure 172: <S3-DEL> PDU header 

27.5 Formats of fields 
27.5.1 General principles 

Field codings are listed in the order of their appearance in the PDUs. 

Unless otherwise stated, all fields shall be coded according to the natural binary code. The resulting value 
shall be arranged with most significant bit (msb) in the highest numbered bit position. Field codings may 
be listed in either binary (B) or hexadecimal (H) format. 

When a field spans more than one octet, the order of bit values within each octet progressively decreases 
as the octet number increases. The lowest bit number associated with the field represents the lowest 
order value. 

The most significant bit shall be transmitted first before interleaving. 



8 


7 


6 


5 


4 


3 


2 


1 












Bit6 
msb 


Bit5 


Bit4 


Bit3 


Bil2 


Bit1 Isb 













1st octet in the field 
2nd octet in the field 



Figure 173: Field Mapping 

Certain elements are reserved (Res). Unless otherwise stated, these elements shall be set to binary "0\ 
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27.5.2 Fixed part fields 
27.5.2.1 Version (4 bits) 

8 7 6 



L 



Version 



octet 1 



The version indicates: 

Bit: 8 7 6 

0 0 0 

All other values reserved. 
27.5.2.2 Type (4 bits) 

8 7 6 



Figure 174: Version field 



Version 0 (of this ETS) 



PDU type 



octet 1 



The PDU type indicates either: 
Bit: 4 3 2 1 



0 
0 



0 

1 



0 
0 



All other values reserved. 
27.5.2.3 Flags (4 bits) 



8 



6 



0 
0 



Figure 175: Type field 



Data PDU 
Delivery PDU 



I FS flag | LA flag I "0" Res I "0" Res I 



octet 2 



Figure 176: Flags field 

FS flag: indicates which protocol subset applies to this PDU: 

FS^O": FULL; or 
FS="1" SLIM. 

LA flag: indicates length of address: 

LS=0 n Long address (6 octets); 
LS= tt 1 w Short address (3 octets). 

27.5.2.4 Packet length (1 2 bits) 

This field indicates total length of the data part in octets. 
Range: 1 to 2 048 for User Data (Data PDUs). 
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27.5.3 Address part fields 

Either short (3 octet) or long (6 octet) addresses as defined by LA flag. 
3 octet address contains the short subscriber identity (SSI). 
6 octet address contains the TETRA Subscriber Identity (TSI). 
Refer to ETS 300 392-1 [11], clause 7. 

27.5.4 Facility part fields 

27.5.4.1 Sub-address 

The contents of this field is defined by the service user, and the value used shall be the same as the value 
supplied in the primitive parameters. 

Any 4-bit value. Allowed range 0 H to F H. 

Reserved values: E H: IP 

F H: ISO CLNP 

27.5.4.2 Priority 

The contents of this field is defined by the service user, and the value used shall be the same as the value 
supplied in the primitive parameters. 

The following values of priority shall be allowed: 

0 H low; 

2 H medium; 

4 H high; 

8 H emergency. 

27.5.4.3 Delivery/storage request 

The contents of this field shall be defined by the service user, and the value used shall be the same as the 
value supplied in the primitive parameters. 

_8 7 6 5 4 3 2 1 

Delivery I Storage | octet 



Figure 177: Delivery/Storage request field 

The delivery/storage request indicates the services required for this packet: 
The delivery field shall indicate either: 

Bit: 8 7 

0 0 Point-to-point 
0 1 Multicast 

All other values reserved. 
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The storage field shall indicate either: 



Bit: 



NOTE: 



6 



0 
0 
1 
1 



0 

1 

0 

1 



None 

Storage A (see note) 
Storage B (see note) 
Storage for at least 72 hours 



The storage time indicated by these codings is implementation dependent, and is not 
defined by this ETS. 



27.5.4.4 Report request 

The contents of this field shall be defined by the service user, and the value used shall be the same as the 
value supplied in the primitive parameters. 

8 7 6 5 4 3 2 1 

Report request I octet 



Figure 178: Report request field 

The report request indicates the class of reports required for this packet. This is a bit mask that allows 
each class of report to be separately selected: 

Bit: 4 3 2 1 

x Final delivery class reports 

x - All positive reports 

x - - All negative reports 

x Reserved 

For each bit position, a "1" indicates that this class of report shall be supplied, and a "0" indicates that this 
class of report shall not be supplied. 

Refer to subclause 27.5.4.5. for a list of possible disposition reports. 

NOTE: Some disposition reports are classified in more than one class. 



27.5.4.5 Disposition 

The disposition field shall be used to code one value of report. Each report is coded in two fields. The 
class field is a bit mask that indicates the report class(es) to which the report belongs. The type field 
distinguishes the different reports within each class. 

8 7 6 5 4 3 2 1 



Report Class I Report Type | octet 



Figure 179: Disposition field 
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Class 


Type 


Description 


Bit 8765 


4321 




0011 


0000 


Successful delivery of pt-pt packet 


0011 


0010 


Successful delivery of stored pt-pt packet 


001 1 


1000 


Successful multicast 


0100 


0000 


Failed delivery - packet discarded 


0100 


0010 


Packet deleted from store 


0100 


0101 


Packet lost - network congestion 


m nn 
Ul UU 


Ul IU 


racKei iosi - cause unKnown 


0110 


0000 


Packet stored for later delivery 


1000 


0000 


Illegal service request - packet discarded 


1000 


0001 


Multicast facility not supported - packet discarded 


1000 


0010 


Invalid area selection - packet discarded 


1000 


0100 


Destination address unknown - packet discarded 


1100 


0010 


Failed delivery and packet storage not supported - packet discarded 



All other values are reserved. 



Class bit 5 (0001) = final delivery reports 
Class bit 6 (0010) = positive reports 
Class bit 7 (0100) = negative reports 
Class bit 8 (1000) = error reports 

This disposition report should only be produced when a packet storage is attempted. Normal delivery shall 
be attempted first, even if an unsupported storage option is requested. 

27.5.4.6 Multicast area selection 

Multicast area selection uses one octet. The contents of this field is defined by the service user, and the 
value used shall be the same as the value supplied in the primitive parameters. 

The multicast area selection value of 00 H is reserved. This dummy value shall be used for "pt-pf 
packets. 

The multicast area selection values of 01 H to OF H are reserved. These values shall be used to encode 
area selection values to correspond to the V+D services. The coding of these values is for further study. 

All other values of multicast area selection shall only be used if "multicast" is indicated in the delivery 
required. The allowed values shall lie in the range 10 H to FE H and the areas associated to these values 
shall be agreed on a per-subscription basis. 

The multicast area selection value of FF H shall be reserved and shall mean "broadcast" or "all areas". 
The provision of this facility shall also be agreed on a per subscription basis. 

27.5.4.7 Timestamp 

The timestamp field is three octets. The timestamp for each PDU shall be set equal to the "absolute 
network time" by the first network node to indicate the time of submission of the packet. 

Absolute network time should be defined as follows: 

1) zero time (0OO000H) is defined as 00:00 hours, Universal Time Co-ordinates (UTC time) on 
January 1st of every year. Absolute network time is therefore reset each year; 

2) absolute network time shall be incremented by one every 2 seconds, and the value of absolute 
network time at all network nodes shall not differ by more than 4 steps (a maximum difference of 8 
seconds); 

3) the value FFFFFFH is reserved and shall be used to indicate an Invalid value of timestamp. This 
value shall be used in all <S1-DT> PDUs and by the infrastructure in the event of network 
malfunction; 
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4) The values F1 42FFH - FFFFFEH are reserved for future use. 
27.5.4.8 Packet route 

This field shall only appear in the <S3-DT> or <S3-DEL> PDU. 

27.5.5 Header checksum 

This field shall only appear in the <S3-DT> or <S3-DEL> PDU. 

The checksum shall be calculated on the entire PDU header, and the resulting octets placed in this field. 

A checksum value of zero is reserved to indicate that the checksum shall be ignored. The operation of the 
PDU header error detection function as described in subclause 27.7.8. ensures that the value zero does 
not represent a valid checksum. A non-zero value indicates that the checksum shall be processed. 

27.5.6 User data part 

For DATA PDUs, the user data shall be supplied in the same primitive (a single SDU) up to a maximum 
limit of 2048 octets. 

For DELIVERY PDUs, the user data shall be the first two octets copied from the corresponding DATA 
PDUs. If the corresponding data PDU contains less than 2 octets, the DELIVERY PDU shall contain all of 
the user data. This octets may be used as a packet signature. 

27.6 Primitive definitions and format 

All primitives are defined in clause 26. 

27.7 Protocol functions 

This subclause describes the functions performed as part of the protocol. 

The functions depend on the role of the protocol instance, and not all the functions shall be implemented 
in each role. Four alternative roles are identified for SCLNP: a send role; a receive role and two forwarding 
roles. Table 357 lists the requirements for each role. 

NOTE: A particular implementation may be required to support more than one role. For 
example, a sending role will usually be combined with a receiving role, 
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Table 357: Provision of protocol functions 





System role 


Ref 


Function 


Send 


Forward 1 
MTUn 


Forward 2 
Infrastructure 


Receive 


10.1 


DT PDU composition 


M 








10.2 


DEL PDU composition 






M 




10.3 


DT PDU decomposition 








M 


10.4 


DEL PDU decomposition 


M 








10.5 


Route PDU 




M (note 3) 


M 




10.6 


Forward PDU 


M 


M 


M 




10.7 


Discard PDU 




M(note1) 


M (note 1) 


M 


10.8 


Header error detection 






I 




10.9 


FACILITY FUNCTIONS: 




10.9.1 


Sub-addressing 


M (note 2) 






M (note 2) 


10.9.2 


Priority 


M (note 2) 


I 


I 


M (note 2) 


10.9.3 


D/S Request 






I 




10.9.4 


Report Request 






M 




10.9.5 


Area selection 






I 




10.9.6 


Timestamp 






M 




10.9.7 


Packet storage 






I 




NOTE 1: Protocol procedure not respected, header that cannot be analysed, PDU whose checksum 

is inconsistent with its content. 
NOTE 2: Included in PDU composition and decomposition. 

NOTE 3: Only required for multiple subscriptions (multiple TSI) attached to one MTU. 



KEY: M: this function shall be implemented; I: implementation option; -: not applicable. 



Forward 1 designates the SCLNP function in the MTU (MTU0 or MTU2 or MTU3). 
Forward 2 designates the forward function of the SCLNP in the TETRA infrastructure. 

27.7.1 Data PDU composition 

This function is responsible for the construction of a data PDU according to the rules governing the 
encoding of PDUs given in subclauses 27.4 and 27.5. Protocol control information required for delivering 
the data unit to its destination shall be determined from the current state and local information and from 
the parameters contained in the associated TL-UNITDATA request primitive. When a forwarding station is 
required to compose one type of PDU from another type, e.g. composing a <S1-DT> PDU from a 
<S3-DT> PDU, the protocol control information in the new PDU shall be determined from the 
corresponding fields in the old PDU. 

In all cases, the PDU TYPE field shall be set to indicate "data", and the VERSION field shall be set to 
indicate "version 0", i.e. this ETS. 

The total length of the USER DATA in octets shall be determined by the originator and the result placed in 
the PACKET LENGTH field. This field shall not be modified when converting the PDU. 

The further operations depend on the location of the composition function. For a PDU that is being 
composed by a MTU for submission to the air interface, the <S1-DT> PDU shall be used. For a PDU that 
is being composed by the infrastructure for submission to the air interface, the <S2-DT> PDU shall be 
used. For a PDU that is being composed by the infrastructure for submission to a Line Station (LS), the 
<S3-DT> PDU shall be used. 

27.7.1 .1 <S1 -DT> PDU composition 

The DESTINATION ADDRESS field shall be derived from the "destination address" parameter (field) in 
the associated primitive (PDU). If this destination address lies in the current network the short address 
format should be used. Otherwise the long address format shall be used. The LA flag shall be set 
according to the address type in use. 

There is no source address field in uplink <S1-DT> PDUs. Instead, the source address shall be defined a 
priori for each instance of SCLNP: each instance shall only be associated to a single value of ISSI. 
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NOTE: A single value of source address (ISSI) can be considered as the definition of "one 
instance" of SCLNP (see also subclause 27.7.5). 

The priority definition of the source address shall be locally created, e.g. in a MS this is assumed to 
require a binding between each particular instance of SCLNP and the MLE. 

If the full protocol is requested, the additional facility fields shall be added as defined in 
subclause 27.7.1 .4. Otherwise these fields shall be omitted. 

27.7.1 .2 <S2-DT> PDU composition 

The SOURCE ADDRESS field shall be derived from the "source address" parameter (field) in the 
associated primitive (PDU). if this source address lies in the current network the short address format 
should be used. Otherwise the long address format shall be used. The LA flag shall be set according to 
the address type in use. 

There is no destination address field in downlink <S2-DT> PDUs. Instead, the destination address shall be 
included as a parameter to the MLE for each packet submission: each submission shall only be 
associated to a single value of ISSI or GSSI. 

If the full protocol is requested, the additional facility fields shall be added as defined in 
subclause 27.7.1 .4. Otherwise these fields shall be omitted. 

27.7.1 .3 <S3-DT> PDU composition 

The SOURCE ADDRESS field shall be derived from the "source address" parameter (field) and the 
DESTINATION ADDRESS field shall be derived from the "destination address" parameter (field) in the 
associated primitive (PDU). The long address format shall be used for both addresses and the LA flag 
shall be set accordingly. 

The facility fields shall always be included in the PDU. If the facility fields contain valid information, this 
shall be indicated by setting the FS FLAG, and the facility fields shall be added as defined in 
subclause 27.7.1 .4. 

In certain cases, the facility fields may contain invalid (null) information (e.g. when the PDU is composed 
by converting a slim uplink PDU as described in subclause 27.7.6). In this case all of the facility fields shall 
be filled with zeros and the FS FLAG shall be cleared. 

27.7.1.4 Composition of facility fields 

The following facility fields shall be derived from the corresponding TN-UNITDATA request primitive: 
SUBADDRESS; 
PRIORITY; 
D/S REQUEST; 
REPORT REQUEST. 

The TIMESTAMP field shall be filled with zeros by the originator of the Initial PDU. This field shall be 
added by the network at the first infrastructure node. 

27.7.2 Delivery PDU composition 

This function is responsible for the construction of a delivery PDU according to the rules governing the 
encoding of PDUs given in subclauses 27.4 and 27.5. Protocol control information required for delivering 
the data unit to its destination shall be determined from the current state and local information. There is no 
associated primitive. When a forwarding station is required to compose one type of PDU from another 
type (e.g. composing a <S2-DEL> PDU from a <S3-DEL> PDU) the protocol control information in the 
new PDU shall be determined from the corresponding fields in the old PDU. 
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Delivery PDUs shall only be composed if the delivery disposition facility has been selected in the 
corresponding data PDU.. 

NOTE: One packet may generate more than one disposition report. 

The PDU TYPE field shall be set to indicate "delivery 11 , and the VERSION field shall be set to indicate 
"version 0", i.e. this ETS. 

The USER DATA field shall be set equal to the first 2 octets of the user data field of the associated DATA 
PDU. If the associated DATA PDU contains less than 2 octets of user data, all of the user data shall be 
copied into the DELIVERY PDU. 

The initial composition of a delivery PDU is assumed to be in the form of a <S3-DEL> PDU. Further 
composition operations depend on the location of the composition function. For a PDU that is being 
composed by the infrastructure for submission to the air interface, the <S2-DEL> PDU shall be used. For 
a PDU that is being composed by the infrastructure for submission to a Line Station (LS), the <S3-DEL> 
PDU shall be used. 

27.7.2.1 <S1 -DEL> PDU composition 
There is no <S1-DEL> PDU. 

27.7.2.2 <S2-DEL> PDU composition 

The SOURCE ADDRESS field shall be derived from the "source address" field of the associated PDU. If 
this source address lies in the current network the short address format should be used. Otherwise the 
long address format shall be used. The LA flag shall be set according to the address type in use. 

There is no destination address field in downlink <S2-DT> PDUs. Instead, the destination address shall be 
included as a parameter to the MLE for each packet submission: each submission shall only be 
associated to a single value of ISSI or GSSI. 

The facility fields shall be added as defined in subclause 27.7.2.4. 

27.7.2.3 <S3-DEL> PDU composition 

The SOURCE ADDRESS field shall be derived from local information and the DESTINATION ADDRESS 
field shall be derived from the "source address" field of the corresponding <DT> PDU. The long address 
format shall be used for both addresses and the LA flag shall be set accordingly. 

The facility fields shall always be included in the PDU. These fields shall always contain valid information 
and this shall be indicated by setting the FS FLAG. The facility fields shall be added as defined in 
subclause 27.7.2.4. 

27.7.2.4 Composition of facility fields 

The following facility fields shall be copied from the associated <S-DT> PDU: 

SUBADDRESS; 

PRIORITY; 

D/S REQUEST; 

REPORT REQUEST. 
The following facility fields shall be supplied by the reporting entity: 

DISPOSITION REPORT; 



TIMESTAMP. 
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The TIMESTAMP field shall be set equal to absolute network time, as defined in subclause 27.5.4.7, by 
the reporting entity. This assumes that the reporting entity is part of the infrastructure. 

27.7.3 Data PDU decomposition 

This function is responsible for removing the protocol control information from the PDU header and 
preparing the TN-UNITDATA indication. The information for the TN-UNITDATA indication shall be 
determined as follows: 

the "source address" parameter shall be derived from the SOURCE ADDRESS field. If the short 
address format was used in the PDU, the current MNC shall be inserted to complete the "source 
address" parameter. The "destination address" shall not be supplied: this shall be defined a priori 
for each instance of SCLNP. 

The following facility fields shall be directly copied into the corresponding TN-UNITDATA indication 
primitive: 

SUBADDRESS; 

PRIORITY; 

D/S REQUEST; 

REPORT REQUEST. 

27.7.4 Delivery PDU decomposition 

This function is responsible for removing the protocol control information from the PDU header and 
preparing the TN-DELIVERY indication. The information for the TN-DELIVERY indication shall be 
determined as follows. 

The "source address" parameter shall be derived from the SOURCE ADDRESS field. If the short address 
format was used in the PDU, the current MNC shall be inserted to complete the "source address- 
parameter. The "destination address" shall not be supplied: this shall be defined a priori for each instance 
of SCLNP. 

The following facility fields shall be directly copied into the corresponding TN-DELIVERY indication 
primitive: 

SUBADDRESS; 

PRIORITY; 

D/S REQUEST; 

REPORT REQUEST; 

DISPOSITION REPORT. 

27.7.5 Route PDU 

This function determines the network entity to which a PDU should be forwarded, and the underlying 
service that shall be used to reach that network entity, using the DESTINATION ADDRESS field of the 
PDU. The results of the route PDU are passed to the forward PDU function along with the PDU itself for 
further processing. 

27.7.6 Forward PDU 

This function issues a suitable primitive to the sub-network service identified by the route PDU function. 
The sub-network-specific address supplied by the route PDU function identifies the next system within the 
sub-network domain This may be an intermediate system or an end system. 



Page 561 

ETS 300 392-2: March 1996 



The forward shall use one of the sub-network services, and the associated primitives, that are described 
in subclause 27.8. 

The forward PDU function may also be required to provide a PDU conversion function, when forwarding 
PDUs to or from the air interface. This conversion function is responsible for the construction of a different 
type of data PDU (or delivery PDU) according to the rules governing the encoding of PDUs given in 
subclauses 27.4 and 27.5. Protocol control information required for the output PDU shall be wholly 
determined from the corresponding fields in the input PDU. 

When converting a slim <S1-DT> PDU into a <S3-DT> PDU the output PDU the facility fields in the output 
PDU have no corresponding fields in the input PDU. In this case the output facility fields shall be filled with 
zeros and the FS FLAG shall be cleared, in accordance with the rules defined in subclause 27.7.1.3. 

27.7.7 Discard PDU 

This function performs all the actions necessary to free the resources reserved by the network entity when 
any of the following situations is encountered: 

a) a violation of a protocol procedure has occurred; 

b) a PDU is received whose header checksum is inconsistent with its contents; 

c) a PDU is received but due to local congestion it cannot be processed; 

d) a PDU is received whose header cannot be analysed; 

e) a PDU is received whose destination address is unreachable or unknown; 

f) a PDU is received which contains an unsupported facility. 
NOTE: The list is not exhaustive. 

27.7.8 PDU header error detection 

This function is based on the corresponding function in IS0.8473 [6]. 

The PDU header error detection function protects against failure of intermediate or end-system network 
entities due to the processing of erroneous information in the PDU header. This function is realised by a 
checksum computed on the entire PDU header. The checksum shall be verified at each point at which the 
PDU is processed. If the checksum calculation fails, the PDU shall be discarded. If PDU header fields are 
modified then the checksum shall be modified so that the checksum remains valid (see note). 

The use of the header error detection function is optional and shall be selected by the originating network- 
entity (see note). If this function is not used, the checksum field of the PDU header shall be set to zero. 

If this function is selected by the originating network entity, the value of the checksum field shall cause the 
following formulae to be satisfied: 

la=0 ... (mod255) 

1=1 (82) 



X(L-i +1)^=0 ... (mod255) 

i=i v (83) 

where L is the number of octets in the PDU header and a/ is the value of the octet in position /. The first 
octet in the PDU header is considered to occupy position 1 . 

When this function is in use, neither octet of the checksum field may be set to zero. 

For the purposes of this subclause, the originating network entity shall refer to the first network entity in 
the originating network that creates a PDU type that contains the header checksum field. 
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Annex C contains description of algorithms which may be used to calculate the correct value of the 
checksum field when the PDU is created, and to update the value of the checksum field when the header 
is modified. 

To ensure that inadvertent modification of a header while a PDU is being processed by an intermediate 
system (e.g. due to a memory fault) may still be detected by the PDU header error function, an 
intermediate system network-entity shall not re-compute the checksum for the entire header, even if fields 
are modified. Refer to the update description in annex C. 

27.7.9 Facility functions 

27.7.9.1 Sub-addressing 

The sub-address facility is provided to allow service users to identify different higher layer protocols. This 
facility allows the originating service user to define any value for the SUBADDRESS field, and this value 
shall be preserved by all intermediate systems, such that the same numeric value of sub-address shall 
always be supplied to the destination user. 

NOTE: The sub-address values are not standardised, and they should not be used to support 
any internal network functions. 

27.7.9.2 Priority 

The priority facility allows a PDU with a numerically higher priority value to be processed preferentially with 
respect to other PDUs with numerically lower priority values by both intermediate and end systems. The 
function is realised by the PRIORITY field in the facility part of the PDU header. 

The lowest priority value is 0 H. The specific action taken by a particular network-entity to support the 
priority facility is a local matter and is not specified in this ETS. 

NOTE: Examples of priority processing include preferential treatment in output queues and in 
buffer allocations. 

27.7.9.3 Delivery/storage request 

The D/S request facility allows a user to request one of defined set of network operations on the data 
PDU. The delivery and storage choices shall be processed independently according to the following 
subclauses. 

27.7.9.3.1 Delivery facility 

The set of alternatives for this facility are defined by the DELIVERY field are described in 
subclause 27.5.4.3. This facility allows the service user to indicate the type of packet delivery that should 
be provided for each PDU. 

The point-to-point value should correspond to the use of an ITSI as the destination address. The 
multipoint value should correspond to the use of a GTSI as the destination address. In all cases, the 
DELIVERY field shall take precedence over any analysis of the DESTINATION ADDRESS with respect to 
all applicable forwarding functions. 

This facility is closely related to the area selection facility, and the originator of the Initial PDU shall also 
provide a value for the AREA SELECTION field that is consistent with the delivery mode selected here 
(see subclause 27.7.9.5). 

27.7.9.3.2 Storage facility 

The set of alternatives for this facility are defined by the STORAGE field are described in 
subclause 27.5.4.3. This facility allows the service user to indicate the relative level of packet storage that 
may be provided for each PDU. 

The specific action taken by a particular network-entity to support the packet storage facility is not 
specified in this ETS. 
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27.7.9.4 Report request 

The set of alternatives for this facility are defined by the REPORT REQUEST field are described in 
subclause 27.5.4.4. This facility allows the service user to indicate the type of delivery disposition reports 
that should be provided for each PDU. 

This facility is closely related to the disposition report facility (see subclause 27.7.9.7). 

27.7.9.5 Multicast area selection 

The set of alternatives for this facility are defined by the AREA SELECTION field as described in 
subclause 27.5.4.5. 

This facility allows the service user to indicate the geographic areas to be used for multicast packet 
delivery. When selecting point-to-point delivery the reserved point-to-point value shall be used. 

The specific action taken by a particular network-entity to support the area selection facility is not specified 
in this ETS. 

27.7.9.6 Time stamping 

The timestamp facility allows the receiving entity, and any infrastructure entities to know the time of 
submission of each packet. This field is set equal to the "absolute network time" by the first infrastructure 
node, and it shall not be modified by any other node. 

The timestamp coding of "absolute network time" is defined in subclause 27.5.4.7. This value is reset 
every year, such that the timestamp is ambiguous for packets that remain in the network for more than 
1 year. 

A timestamp value that is greater than the current value of "absolute network time" should be interpreted 
as referring to the previous year. 

A timestamp coded with the reserved "invalid" value shall be ignored. 

27.7.9.7 Disposition report 

This facility allows the infrastructure to generate disposition reports for data PDUs that can be used by the 
originating service user to monitor the progress of a PDU through the network. 

This facility is closely related to the report request facility (see subclause 27.7.9.4) and all originators of 
delivery PDUs shall only generate delivery PDUs in accordance with the rules contained in this subclause. 

Any forwarding protocol entity may generate a disposition report. The allowed values for the 
DELIVERY REPORT field are described in subclause 27.5.4.5. 

A protocol entity shall only generate a disposition report if there is a match between the requested class, 
as indicated by the REPORT REQUEST field, and the REPORT CLASS sub-field. If a bit-wise logical 
AND of the REPORT REQUEST field and the REPORT CLASS sub-field produces a non-zero result, a 
delivery PDU may be generated. If it produces a zero result the disposition report shall be discarded an no 
delivery PDU shall be generated. 

27.8 Provision of the underlying service 

27.8.1 General 

Convergence functions may be required to provide the underlying connectionless mode service assumed 
by this protocol. If the lower layer inherently provides a connection mode service, this convergence 
function provides a mapping into the required services. 

Convergence functions may also be required in those cases where functions assumed from the underlying 
service are not performed. In some cases this may require the operation of an explicit protocol. 
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27.8.2 Operation over MLE 

The SCLNP is intended to be capable of operating over the MLE using the services provided at the 
LSCL-SAP (see clause 17). The MLE sub-layer manages the radio resources, the radio link and the 
addresses and provides convergence to the packet data optimised layer 2, which is optimised for air 
interface operation. 

The underlying service at the LSCL SAP consists of the primitives described in clause 17: 

MLE- CLOSE indication: to indicate that access to the MM link has been removed; 

MLE- OPEN indication: to inform access to the link; 

MLE-UNITDATA request: to send data; 

MLE-UNITDATA indication: to indicate the arrival of data. 

When issuing primitives to the MLE, the SCLNP shall map the abstract TSN-UNITDATA request to 
MLE-UNITDATA request primitive. The parameters of this primitive shall be set according to the following 
rules: 

1) all downlink primitives that indicate "multicast" in the DELIVERY field of the PDU (full SCLNP only) 
shall be mapped onto a MLE-UNITDATA request primitive with the layer 2 service parameter set 
equal to "unacknowledged"; 

2) a uplink or downlink primitive that indicate "class 2" in the QoS parameter may be mapped onto a 
MLE-UNITDATA request primitive with the layer 2 service parameter set equal to 
"unacknowledged"; 

3) all other cases shall be mapped to a MLE-UNITDATA request primitive with the layer 2 service 
parameter set equal to "acknowledged request". 

Equivalent mappings shall apply to primitives received from the MLE. 

27.9 Conformance 

For conformance to this ETS the ability to originate, manipulate and receive PDUs in accordance with the 
full protocol is required. 

Additionally, conformance to this ETS requires provision of the protocol functions described in 
subclause 27.7. The functions required for conformance of a particular implementation are listed in 
table 357. 

Additionally conformance to this ETS requires adherence to the structure and encoding of PDUs as 
described in subclauses 27.4 and 27.5. 

27.1 0 Algorithms for PDU header error detection function 

NOTE: The contents of this subclause are derived from annex C of IS0.8473 [6]. The octet 
numbers are modified to correspond to the SCLNP <S3-xxx> PDUs. 
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27.10.1 Symbols used in algorithms 

C(o), C(i) are variables used in the algorithm; 

/is the number (i.e. position) of an octet within the header (the position of the first octet is /= 1); 
O/is the value of octet / of the PDU header; 

n is the number (i.e. position) of the first octet of the checksum parameter {n = 23); 

L is the length of the PDU header in octets; 

X is the value of octet one of the checksum parameter; 

Vis the value of octet two of the checksum parameter. 

27.10.2 Arithmetic conventions 

Addition is performed in one of the two following modes: 

a) modulo 255 arithmetic; 

b) eight-bit one's complement arithmetic in which, if any of the variables has the value 
minus zero (i.e. 255) it shall be regarded as though it had the value plus zero (i.e. 0). 

27.10.3 Algorithm for generating checksum parameters 

Construct the complete PDU header with the value of the checksum parameter field set to zero: 



a) 

C 0 <-C 7 <- 0 (84) 

b) Process each octet of the PDU header sequentially from / = 1 to L by: 

Co^Co+Oi (85) 
C 1 «- C 1 + C 0 (86) 

c) Calculate: 

X<- (L • 23) C 0 • C 1 (mod 255) (87) 

V<- (L -22) ( - C 0 ) + C 1 (mod 255) (88) 

d) 

ifX=0,thenX<-255 (89) 
e) 

if V=0,then V<-255 (90) 
f) place the values of X and Vin octets 23 and 24 respectively. 
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27.1 0.4 Algorithms for checking checksum parameters 

a) If octets 23 and 24 of the PDU header both contain 0 (all bits off), then the checksum calculation 
has succeeded, else if either but not both of these octets contains the value zero then the 
checksum is incorrect; otherwise initialise: 

C^Co^Co (91) 

b) Process each octet of the PDU header sequentially from / = 1 to L by: 

C 0 <-C 0 ^0 (92) 
C f <- C 7 <- C 0 (93) 

c) If, when all the octets have been processed: 

C 0 =C 1 = H 0 m (mo6 2S5) (94) 
then the checksum calculation has succeeded; otherwise the checksum calculation has failed. 

27.10.5 Algorithm to adjust the checksum parameter when an octet is altered 

This algorithm adjusts the checksum when an octet such as the timestamp field is altered. Suppose the 
value in octet k is changed by Z= new value - old value. 

If X and Y denote the checksum values held in octets n and ah-1 , respectively, then adjust X and Y as 
follows: 

If X = "O" and V= "O" then do nothing, else if X = "0" or V= "0" then the checksum is incorrect, else: 
X<- (k -n - 1) Z + X(mod 255) (95) 
Y <- (n - A) Z + Y (mod 255) (96) 
If X= 0, then X<- 255; if Y = 0, then V<- 255 

For this protocol, n = 23. If the octet being altered is the last octet of the timestamp field, k = 19. For the 
case where the timestamp is decreased by one unit (z = -1), the assignment statements for the new 
values of Xand Y in the immediately preceding algorithm simplify to: 

X<- /+ 5 (mod 255) (97) 

Y<r- 4 (mod 255) (98) 

To derive this result, assume that when octet k has the value Z added to it then Xand /have values Z x 
and Zy added to them. For the checksum parameters to satisfy the conditions of subclause 27.7.8. both 
before and after the values are added, the following is required: 

Z + Z x + Z y = V (mod 255) (99) 
(L-k-h1)Z-h(L-n-h1)Z x -h(L-n)Z y =V a (mod 255) ( 1 00) 

Solving these equations simultaneously yields 

Z x = (fc-n-1)Z (101) 
Zy = (n-k)Z 002) 
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Annex A (normative): LLC timers and constants 

This annex lists the LLC timers and constants in the MS. 

Where indicated, a value should be chosen by the MS designer from within a given range. For the other 
timers and constants, a default value is given. The default value shall be used by the MS unless it 
received a different value when it subscribed to that network. 

A.1 LLC timers 

Timers T.251, T.252, T.261 and T.263 are defined in terms of downlink signalling frames for the control 
channel on which the downlink message is expected. When counting downlink signalling frames, the MS 
should normally count all frames, except that: 

on an assigned channel, the MS shall count only those downlink frames that are available for 
control signalling on that channel; note, however, that the BS may choose to send a PDU to the MS 
by stealing from the downlink TCH; 

if the MS is transmitting traffic then: 

for timer T.251 , and if the stealing repeats flag is set for the PDU being sent, the MS shall 
count all downlink frames (irrespective of whether they are available for control signalling); 

otherwise, the MS shall count only those downlink frames that it is required to monitor 
(according to the assigned monitoring pattern(s)) and that are available for control signalling; 

if the MS is in minimum mode, the MS shall count only frame 18; note, however, that the BS may 
choose to send a PDU to the MS in slot 1 during frames 2-17; 

on a time-shared MCCH, the MS shall count only frames reserved for this BS; note, however, that 
the BS may choose to send a PDU to the MS in one of the common frames. 

T.251 Sender re-try timer 

Default value = 4 signalling frames. 
T.252 Acknowledgement waiting timer 

Default value = 9 signalling frames. 
T.261 Set-up waiting timer 

Default value = 4 signalling frames. 
T.263 Disconnection waiting timer 

Default value = 4 signalling frames. 
T.271 Receiver not ready validity timer for the data sending entity 

Default value = 36 TDMA frames. 

NOTE: The value of this timer should exceed the value for the data receiving entity T.272. 
T.272 Receiver not ready validity timer for the data receiving entity 
Default value = 18 TDMA frames. 
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A.2 LLC constants 

Constants N.252, N.253, N.262, N.263, N.273, N.274 and N.282 define the maximum number of re- 
transmissions or repetitions. The maximum number of transmissions (including the first transmission) is 
therefore the specified value + 1 . 

N.251 Maximum length of TL-SDU (basic link) 

This is the maximum length of one TL-SDU if the optional Frame Check Sequence (FCS) is used. 
Default value = 2 595 bits (i.e. approximately 324 octets). 

The FCS is optional. If the FCS is not used, the TL-SDU part may be larger by four octets. 

N.252 Maximum number of TL-SDU re-transmissions for acknowledged basic link service 

MS designer choice from range 3 to 5 if the stealing repeats flag is set; 
MS designer choice from range 1 to 5 if the stealing repeats flag is not set. 

N.253 Number of TL-SDU repetitions in unacknowledged basic link service 

MS designer choice from range 1 to 5. 

N.261 Advanced link number 

This value is defined during the set-up of the advanced link (see AL-SETUP PDU definition). 
Range: (1; 4). 

N.262 Maximum number of connection set-up retries 

MS designer choice from range 1 to 5. 
N.263 Maximum number of disconnection retries 

MS designer choice from range 3 to 5. 

N.264 Number of timeslots used per TDMA frame 

This value is defined during the set-up of the advanced link (see AL-SETUP definition). 
Range: (1;4). 

N.271 Maximum length of TL-SDU (advanced link) 

This is the maximum length of one TL-SDU including the FCS, it is defined during the set-up of the 
advanced link (see AL-SETUP PDU definition), Range: (32, 4 096) octets. 

N.272 Window size for TL-SDU in acknowledged service 

This value is defined during the set-up of the advanced link, (see AL-SETUP definition). 
Range: (1;3). 

N.273 Maximum number of TL-SDU re-transmissions 

This value is defined during the set-up of the advanced link (see AL-SETUP definition). 
Range: (0;7). 

N.274 Maximum number of segment re-transmissions 

This value is defined during the set-up of the advanced link, (see AL-SETUP definition). 
Range: (0;15). 
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N.281 Window size for TL-SDU in unacknowledged service 

This value is defined during the set-up of the advanced link (see AL-SETUP definition). 
Range: (1;3). 

N.282 Number of repetitions for unacknowledged information 

This value is defined during the set-up of the advanced link (see AL-SETUP definition). 
Range: (0;7). 
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Annex B (normative): MAC timers and constants 

This annex lists the MAC timers and constants in the MS. 

Where indicated, a value should be chosen by the MS designer from within a given range. For the other 
timers and constants, a default value is given. The default value shall be used by the MS unless it 
received a different value when it subscribed to that network. 

B.1 MAC timers 

Timers T.202 and T.206 are defined in terms of downlink signalling frames for the control channel on 
which the downlink message is expected. When counting downlink signalling frames, the MS should 
normally count all frames, except that: 

on an assigned channel, the MS shall count only those downlink frames that are available for 
control signalling on that channel; note, however, that the BS may choose to send a PDU to the MS 
by stealing from the downlink TCH; 

if the MS is transmitting traffic then the MS shall count only those downlink frames that it is required 
to monitor (according to the assigned monitoring pattern(s)) and that are available for control 
signalling; 

if the MS is in minimum mode, the MS shall count only frame 18; note, however, that the BS may 
choose to send a PDU to the MS in slot 1 during frames 2-17; 

on a time-shared MCCH, the MS shall count only frames reserved for this BS; note, however, that 
the BS may choose to send a PDU to the MS in one of the common frames. 

T.201 Event label inactivity time-out 

Default value = 30 multiframes 
T.202 Fragmentation time-out 

Default value = 9 downlink signalling frames 
T.205 Random access time-out 

MS designer choice from 5 to 60 multiframes 
T.206 Reserved access waiting time-out 

Default value = 18 downlink signalling frames 
T.208 Inactivity time-out on assigned SCCH 

Default value = 30 multiframes 
T.209 Inactivity time-out on traffic channel 

Default value = 18 multiframes 
T.21 0 Timer for returning to energy economy mode 

Default value = 18 TDMA frames 
T.21 1 AACH time-out for transmission of TCH 

Default value = 36 TDMA frames 
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T.21 2 AACH time-out for reception of TCH 

Default value = 1 8 TDMA frames 
T.21 3 DTX timer 

Default value = 18 TDMA frames 
T.21 4 Stealing timer 

Default value = 6 uplink opportunities 

NOTE: For correct operation of the procedures, T.206 > T.202 
B.2 MAC constants 
N.202 Maximum size of TM-SDU 
2 632 bits (i.e. 329 octets) 
N.208 Number of wrong AACHs to leave assigned channel 

Default value = 3 
N.210 Quality threshold for serving cell 

Default value = 4 
N.21 1 Number of invalid AACHs to stop transmission of TCH 

Default value = 3 
N.212 Number of invalid AACHs to stop reception of TCH 

Default value = 3 
N.21 3 Number of valid AACHs to allow reception of TCH 

Default value - 3 
N.21 4 Number of transmissions if stealing repeats flag is set 

Default value = 4 
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Annex C (normative): Mathematical definition of Frame Check Sequence 

(FCS) 

The FCS value corresponding to a given frame is defined by the following procedure: 

1) the first 4 octets (first 32 bits) of the frame are complemented. If there are less than 32 bits, then 
those bits will be complemented; 

2) the n bits of the frame are then considered to be the coefficients of a polynomial M(x) of degree n-1 ; 

3) M(x) is multiplied by x 32 and divided by G(x), producing a remainder R(x) of degree less than 31 ; 

4) the coefficients of R(x) are considered to be a 32-bit sequence; 

5) the 32-bit sequence is complemented and the result is the FCS. 
As described in ISO 3309 [2], the generator polynomial is defined as: 

G( x )=1 + X+X 2 + X 4 + X 5 +X 7 +X 8 +X 10 + X 11 + X 12 + X 16 + X 22 +X 23 + X 26 + X 32 
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Annex D (informative): MAC scenarios for use of traffic channel 

This annex shows some examples of scenarios for use of an assigned channel for a circuit mode call. It 
demonstrates methods for using the MAC TMD-SAP procedures described in subclause 23.8 and shows 
some possible CMCE signalling scenarios. 

The BS may use the protocol facilities provided for call set-up and channel usage for circuit mode calls in 
many different ways. For example: 



Early, Medium or Late Assignment; 

Transmission, Quasi-transmission or Message Trunking; 



Simplex or Duplex calls; 

different strategies in case of transmission errors. 



Figure D1 to figure D10 illustrate a few examples of signalling related to circuit mode calls. It should be 
noted that there are many other possible scenarios depending on the BS's methods for allocating 
resources. It should also be noted that some of the features represented here are optional. 

In the figures, * beside a BS PDU represents a channel change command. In all the examples shown, the 
position of any slot grant is on the allocated channel. 
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Figure D.1: Initial access message exchange in group call set-up procedure 
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Figure D.1 illustrates a call set-up of a group call on a single cell (without presence indication). The 
assigned channel is on the main carrier, so no CLCH is needed. The D-CONNECT PDU authorises the 
calling MS to start transmitting traffic on the assigned channel and the D-SETUP PDU authorises the 
called members of the group to receive traffic. In this example, the BS does not grant a subslot for the 
calling MS's layer 2 acknowledgement to the D-CONNECT PDU, so the MS steals from the first traffic 
slot. On the downlink, the BS replaces the half slot with the Null PDU on STCH. The BS may send back- 
up D-SETUP PDUs (not shown) to the called group. 

In figure D.1, the BS instructs the calling MS to send a layer 2 acknowledgement to the D-CONNECT 
PDU. This is an optional feature. For example, the BS may choose instead to send the D-CONNECT PDU 
several times without demanding the layer 2 acknowledgement and so allowing TCH to start one half slot 
earlier. This general principle applies also to other figures in this annex. 
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Figure D.2: Initial access message exchange in group call set-up procedure 

Figure D.2 illustrates another call set-up of a group call on a single cell (without presence indication). The 
assigned channel is not on the main carrier, so the BS gives "Immediate CLCH Permission" to the calling 
MS with the channel allocation. In this example, the BS grants the second subslot (after the CLCH) for the 
calling MS's layer 2 acknowledgement; the MS can then start full-slot TCH in the next slot 2. The BS also 
gives "Immediate CLCH permission" with the first D-SETUP PDU to the group members. In the example, 
the BS sends a back-up D-SETUP message on the MCCH. There is "No Immediate CLCH Permission" in 
the back-up message, because the calling MS has already started traffic transmission. 

In figure D.2, traffic from the source is not available for transmission in the first downlink slot on the 
allocated channel. The BS therefore sends C-plane STCH + STCH on the downlink, in this case 
containing null C-plane signalling, until traffic from the source is available. 
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Group encrypted call, no presence indication, same cell, change of carrier 
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Figure D.3: End-to-end signalling for starting encryption of speech (group call) 

Figure D.3 is similar to figure D.2 except that this call uses end-to-end encryption, so the calling MS steals 
from the first traffic slot to send U-plane signalling. This message is passed on to the receiving group. 

Figure D.4 illustrates a call set-up of an individual call on a single cell (with direct call set-up). The BS 
checks the availability of the called MS before allocating a traffic channel. The assigned channel is on the 
main carrier, so no CLCH is needed. In this example, the BS sends D-CONNECT-ACK with the channel 
allocation to the called MS, authorising it to receive traffic. However, it waits for the called MS to respond 
before authorising the calling MS to start transmitting traffic (D-CONNECT PDU). 

In the example shown, the BS receives a layer 2 acknowledgement from the called MS in the granted 
subslot. If it had not received a PDU in the granted subslot, then it cannot know whether it was the 
downlink message that failed or only the uplink response. So it does not know whether the MS is still 
receiving the MCCH or whether it has moved to slot 2. Using the method illustrated, the BS can repeat the 
D-CONNECT ACK on the MCCH and also page the MS on slot 2 until it receives a layer 2 
acknowledgement on slot 2. The BS can then authorise the calling MS to transmit. 
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Individual call, direct set-up signalling, same cell, no change of carrier 
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Figure D.4: Initial access message exchange in individual call set-up procedure 



The signalling method shown in figure D.4 can be used more generally when there may be a queuing 
delay between. D-CALL PROCEEDING and channel allocation. Whereas, in the case illustrated, with no 
queuing delay, the BS could have delayed the D-CALL PROCEEDING until channel allocation (replacing 
D-INFO). 

Alternatively to the method shown in figure D.4, the BS may send D-CONNECT to the calling MS with the 
channel allocation (instead of D-INFO). This method is illustrated in figure D5. It can be seen that this 
allows TCH to start one half slot earlier. However, if the called MS misses the D-CONNECT ACK PDU, it 
will not receive the first part of the traffic. Also, for repeat signalling, the BS must either use the 
unacknowledged service or grant a subslot on the MCCH (i.e. before the channel change) or delay the 
layer 2 acknowledgement until frame 18. 
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Individual call, direct set-up signalling, same cell, no change of carrier 
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Figure D.5: Initial access message exchange in individual call set-up procedure 
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Figure D.6 is similar to figure D.4, but with a change of carrier. 

Individual call, direct set-up signalling, same ceil, change of carrier 
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Figure D.6: Initial access message exchange in individual call set-up procedure 
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Figure D.7 is similar to figure D.6, except that this call uses end-to-end encryption. 

Individual encrypted call, direct set-up signalling, same cell, change of carrier 
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Figure D.7: End-to-end signalling for starting encryption of speech (individual call) 
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Figure D.8 shows an example of signalling at the end of an "over" in an individual call. In this example, the 
BS requires confirmation of receipt of D-TX-CEASED from both MSs. 
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Figure D.8: End of transaction sequence in circuit mode 
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Figures D.9 and D.10 show options for signalling at the start of subsequent "overs" for a message trunked 
call. The BS may prefer to wait for an acknowledgement from the receiving party before giving transmit 
permission, as in figure D9. Or it may give transmit and receive permission at the same time, as in figure 
D.10 (risking some loss of traffic by the recipient). 
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Figure D.9: Start of subsequent transaction in circuit mode 
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Figure D.10: Start of subsequent transaction in circuit mode 
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